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

时间:2012-01-09 12:37:58

标签: c# unit-testing nunit

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

    [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个测试用例(可能将重复的代码重构为另一种方法),因为测试应该仅测试单个事物,但也许我的解释是错误的。

6 个答案:

答案 0 :(得分:18)

用最简单的话来说,IMO测试哪种不做的方法可能会非常滑,因为你可以在考虑时提出越来越多的场景。反过来说,断言你的代码你打算做的事情就是单元测试的目的。


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

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

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

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

结论

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

答案 1 :(得分:6)

制作一个方法可以测试被测方法是否会在您预期时抛出异常,这样做更有意义。您所做的第一个测试没有声明第二个测试尚未涵盖的行为。

答案 2 :(得分:2)

我总是测试工作和非工作情况。这样,您可以验证代码是否有效,返回正确的结果,以及以预期的方式处理错误。

答案 3 :(得分:1)

Imo,如果你确定在InsertionSortedSet列表工作(我不知道它来自哪里),如果有必要,我会跳过你想要做的InsertionSortedSet_AddValues_NoException测试。

当然,最好尽可能多地进行测试。

答案 4 :(得分:1)

这里没有100%正确答案。

一方面你是对的,一次测试应该测试一件事 在其中一个测试将来可能发生变化的情况下尤其如此,然后您无法确定是否要检查其他测试是否通过。

另一方面,您正在创建冗余,因为两个测试实际上都检查了相同的事情 只有在你的测试需要花费太多时间才能运行的情况下,这种冗余才会很糟糕,但由于(看起来像)你只有少量测试,这应该不是问题。

答案 5 :(得分:1)

第一次测试中没有断言或预期的异常,我认为应该重构。

IMO,一个测试应该检查不正确的行为(期望抛出错误),另一个测试应该检查正确的行为(没有异常,返回好的值)。