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

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

Answer 3

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

Answer 4

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

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

Answer 5

这里没有100％正确答案。

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

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

Answer 6

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

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

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

6 个答案:

结论