我应该测试那些方法不会抛出异常吗？

Question

我正在进行单元测试的第一步,并编写了(以及其他)这两种方法:

    [TestCase]
    public void InsertionSortedSet_AddValues_NoException()
    {
        var test = new InsertionSortedSet<int>();

        test.Add(5);
        test.Add(2);
        test.Add(7);
        test.Add(4);
        test.Add(9);
    }

    [TestCase]
    public void InsertionSortedSet_AddValues_CorrectCount()
    {
        var test = new InsertionSortedSet<int>();

        test.Add(5);
        test.Add(2);
        test.Add(7);
        test.Add(4);
        test.Add(9);

        Assert.IsTrue(test.Count == 5);
    }

NoException真的需要这种方法吗？如果要抛出异常,它也将被抛出CorrectCount.

我倾向于将它保留为2个测试用例(可能将重复的代码重构为另一种方法),因为测试应该只测试单个事物,但也许我的解释是错误的.

Answer 1

用最简单的话来说,IMO测试哪种方法不会做得很滑,因为你可以在想到它时提出越来越多的场景.反过来说,断言你的代码完成你打算做的事情就是单元测试的目的.

有两个简单的问题,通常可以帮助我发现可疑的测试并解决测试是否有任何意义:

• 所需功能的哪一部分是测试锻炼？
• 我可以在测试类中进行哪些简单的更改来打破测试？

请注意,处理那些考虑了第二次测试()的问题非常容易_CorrectCount.我们还没有真正看到Add方法代码,但我们很可能会产生可观的猜测可以改变以打破该测试.经过测试的功能更加明显.答案很直观,看起来很快(这很好!).

现在让我们尝试回答第一个测试的问题(_NoException).它立即提出了新的问题(工作代码是否是一个实际的功能？是不是很明显？这不是暗示吗？这不是我们一直在努力的吗？为什么最后没有断言？我怎么能让它失败？ ？).对于第二个问题,情况更糟 - 打破那个测试可能需要明确地抛出异常......我们都同意这不是要走的路.

结论

很简单.第二次测试是精心编写的单元测试的完美示例.它很简单,它测试单一的东西,它可以很容易想出来.第一次测试不是.即使它简单而且(似乎是)简单,它引入了新的问题(虽然它真的应该回答已经陈述的问题 - 实际上是否Add添加？是的.) - 结果带来了不必要的复杂性.

Answer 2

更有意义的是,制作一个方法来测试被测方法在您期望的时候抛出异常.您所做的第一个测试没有断言第二个测试没有涵盖的行为.