Question

对基于测试的开发不熟悉，这个问题一直困扰着我。多少是太多了？应该测试什么，应该如何测试，以及为什么要进行测试？给出的例子是在C＃中使用NUnit，但我认为问题本身与语言无关。

以下是我自己的两个当前示例，对通用列表对象进行测试（使用字符串进行测试，初始化函数添加三个项{"Foo", "Bar", "Baz"}）：

[Test]
public void CountChanging()
{
    Assert.That(_list.Count, Is.EqualTo(3));
    _list.Add("Qux");
    Assert.That(_list.Count, Is.EqualTo(4));
    _list[7] = "Quuuux";
    Assert.That(_list.Count, Is.EqualTo(8));
    _list.Remove("Quuuux");
    Assert.That(_list.Count, Is.EqualTo(7));
}

[Test]
public void ContainsItem()
{
    Assert.That(_list.Contains("Qux"), Is.EqualTo(false));
    _list.Add("Qux");
    Assert.That(_list.Contains("Qux"), Is.EqualTo(true));
    _list.Remove("Qux");
    Assert.That(_list.Contains("Qux"), Is.EqualTo(false));
}

代码是相当自我评论的，所以我不会介绍正在发生的事情，但是这种事情是否过于遥远？当然，Add()和Remove()是单独测试的，那么我应该使用这些类型的测试达到什么水平？我应该进行这类测试吗？

Answer 1

我会说你实际测试的是等价类。在我看来，添加到包含3个项目或7个项目的列表之间没有区别。但是，0项，1项和＆gt; 1项之间存在差异。我最初可能会为这些案例的添加/删除方法分别进行3次测试。

一旦错误开始从QA /用户进入，我会将每个这样的错误报告添加为测试用例;通过红条看到错误的重现;通过获得绿色条来修复错误。每个这样的'错误检测'测试都可以保留 - 这是我的安全网（阅读：回归测试），即使我再次犯这个错误，我也会得到即时反馈。

Answer 2

将您的测试视为规范。如果您的系统在没有测试失败的情况下可能中断（或存在重大错误），那么您没有足够的测试覆盖率。如果一个单点故障导致许多测试中断，则可能有太多（或者耦合太紧）。

这很难以客观的方式定义。我想我会在测试方面说错了。然后，当测试开始惹恼你时，那些是重构/重用的特殊测试（因为它们太脆弱，或者测试错误的东西，并且它们的失败没有用）。

Answer 3

一些提示：

每个测试用例只应测试一件事。这意味着测试用例的结构应该是“setup”，“execute”，“assert”。在您的示例中，您将混合这些阶段。尝试将测试方法分开。这样可以更容易地确切地看到您正在测试的内容。
尝试为测试方法提供一个描述其测试内容的名称。即包含在ContainsItem（）中的三个测试用例变为：containsReportsFalseIfTheItemHasNotBeenAdded（），containsReportsTrueIfTheItemHasBeenAdded（），containsReportsFalseIfTheItemHasBeenAddedThenRemoved（）。我发现强迫自己想出一个像这样的描述性名称，这有助于我在编写实际测试代码之前对我必须测试的内容进行概念化。
如果您使用TDD，您应该编写测试第一，并且只有在测试失败时才将代码添加到您的实现中。即使你实际上没有这样做，它也会让你知道有多少测试就足够了。或者使用覆盖工具。对于像容器这样的简单类，你应该以100％的覆盖率为目标。

Answer 4

_list是你写的一个类的实例吗？如果是这样，我会说测试是合理的。虽然在这种情况下，为什么要构建自定义List类？

如果不是您编写的代码，请不要测试它，除非您怀疑它有某种错误。

我尝试测试独立且模块化的代码。如果我必须维护代码中存在某种神函数，我尽可能多地将其删除到子函数中并独立地测试它们。然后可以将上帝函数写成“明显正确” - 没有分支，没有逻辑，只是将一个经过良好测试的子函数的结果传递给另一个。

测试用例，“何时”，“什么”和“为什么”？

4 个答案: