测试属性4 –准确性

这是关于测试属性的第四篇文章，在现在更为著名的“ 如何测试您的测试 ”文章中对此进行了介绍。 如果您想进行测试方面的培训和/或指导，请与我联系 。

准确性在于查明失败代码的位置。 如果我们知道有问题的代码在哪里，我们可以轻松地分析导致问题的原因，然后继续解决问题。

一个简单的例子是检查不同方法的测试。 当然，如果其中之一发生故障，我们知道在哪里寻找。

这是使用相同方法的另一种简单情况。 我们有一个PositiveCalculator类，它的Add方法将两个正数相加，或者如果它们不是正数，则抛出异常：

public int Add(int a, int b)
{
    if ((a < 0) || (b < 0))
        throw new ArgumentException();

    return a + b;
}

然后，我们可以编写以下测试：

[Test]public void AddTwoPositiveNumbers_GetResult()
{
    PositiveCalculator calculator = new PositiveCalculator();
    Assert.That(calculator.Add(2, 2), Is.EqualTo(4));
}

[Test]public void AddTwoNegativeNumbers_Exception()
{
    PositiveCalculator calculator = new PositiveCalculator();
    Assert.Throws<ArgumentException>
        (() => calculator.Add(-5, -5));
}

查看测试，我们已经看到它们检查两种不同的行为。 当我们结合从测试中读取的内容以及经过测试的代码时，很容易将代码的各个部分与每个测试相关联。 因此，如果其中之一发生故障，我们将知道在哪里寻找。

不幸的是，代码并不总是像这样。 它通常以这种方式开始，但随后逐渐发展为庞然大物。 当它发生时，它要么变得不可测试，要么进行大型，相互重叠的测试，并测试多种事物。 这些都不是准确的测试。

所以，我们能做些什么？

让我们从预防措施开始：不要让代码增长。 毫不留情地保持方法小巧，并使用“单一责任原则”将代码提取为更小，易于测试和准确的功能。

但是我没有写这段代码！

如何使测试准确无误？

这是您可以做的。 现在您已经有了一个或多个测试，是时候使用它们了：开始重构代码。 进行适当的测试会告诉您是否要破坏东西，并且很容易返回工作模式，因为重构也需要很短的步骤。

将代码分解成较小的代码后，您现在可以编写较小的测试，从而为您提供大型测试所没有的准确性。 实际上，如果大型测试在相同的覆盖范围内能提供更好的信息和更好的性能，则可能要用一些较小的测试代替。

我们还可以使用以下方法使测试更加准确：

• 每次测试一项断言–仅检查一件事时，您的测试可能比检查多项检查时更为准确。 如果您的测试中有更多的断言，请将它们分成多个测试。
• 测试更短的场景–在旧代码中，测试大型场景很诱人，因为该代码具有很多功能，并且不会将入口点暴露给单个操作。 尝试测试较短的场景而不是较长的场景，以及较小的对象而不是大型对象。 尝试将长假分为短假。 如果使用大型测试重构代码，则可以编写更小，更准确的测试。
• 模拟不相关的东西-如果您的依赖项执行多项任务，因此会产生更长的场景，请模拟它们。 您现在可以通过您感兴趣的相关代码运行测试，从而使测试更加准确。
• 检查覆盖范围–如果可能，目视检查。 能够以可视方式显示代码的IDE和工具很棒，因为它们为受影响的代码的位置增加了另一条直观的线索。 在琐碎的代码上，它们无关紧要，但是在复杂的代码上，您可以比较不同测试的路径，通过应用一些消除方法，您可以找出问题所在。 您还可以将视觉路径用作测试准确性的反馈，如果不是，请使其更准确。

准确性有助于我们快速解决问题。 但这绝对不是那么容易，因为它很大程度上取决于测试的代码。 但是，结合使用我建议的方法，并利用测试工作来重构和简化测试，绝对可以达到测试精度。

翻译自: https://www.javacodegeeks.com/2014/07/test-attribute-4-accuracy.html