问单元测试文档

EN

根据Thorsten79的要求，我将详细说明我的评论作为答复。我最初的评论是：

不幸的是，“代码说话”是完全错误的，因为一个非开发人员不能阅读代码，而他至少可以部分地读取和理解生成的文档，这样他就可以知道测试的内容。在客户完全理解域而无法读取代码的情况下，这一点尤其重要，而且当单元测试也测试硬件时(比如在嵌入式世界中)，这变得更加重要，因为然后您测试了可以看到的东西。

当你做单元测试时，你必须知道你是只为你自己(或你的同事)写的，还是也是为其他人写的。很多时候，您应该为读者编写代码，而不是为了方便。

在像我公司这样的软硬件混合开发中，客户知道他们想要什么。如果他们的现场设备在接收到某个总线命令时必须进行重置，则必须有一个单元测试来发送该命令，并检查设备是否被重置。我们现在使用NUnit作为单元测试框架和一些定制的软件和硬件来实现这一点，这些软件和硬件使得发送和接收命令(甚至按按钮)成为可能。这很好，因为唯一的选择是手动完成所有这些操作。

客户绝对想知道哪些测试在那里，他甚至想自己运行这些测试。如果测试没有被正确地记录下来，他就不知道测试是做什么的，也不能检查他认为自己需要的所有测试是否都在那里，而且在运行测试时，他也不知道它会做什么。因为他看不懂密码。他比我们的开发人员更了解用过的总线系统，但他们就是看不懂代码。如果测试失败，他不知道为什么，甚至不能说出他认为测试应该做什么。这可不是件好事。

正确地记录了单元测试之后，我们已经

• 供开发人员使用的代码文档
• 客户的测试文档，可以用来证明设备做了它应该做的事情，即客户所订购的东西。
• 以任何格式生成文档的能力，甚至可以传递给其他相关方，如制造商。

在这个上下文中，正确的意思是:写出非开发人员可以理解的清晰语言。你可以保持技术水平，但不要只写你能理解的东西。当然，后者对于任何其他注释和代码也很重要。

独立于我们的确切情况，我认为这是我一直想要的单元测试，即使它们是纯软件。客户可以忽略他不关心的单元测试，比如基本功能测试。但只要有医生就没什么坏处。

正如我在对另一个答案的评论中所写的:此外，如果您(或您的老板、同事或测试部门)想要检查哪些测试以及它们所做的工作，那么生成的文档也是一个很好的起点，因为您可以在不深入研究代码的情况下浏览它。

测试代码本身中的：

• 有方法级的注释来解释测试的内容。
• 在类级别上，一个注释，指示要测试的实际类(这实际上可以从测试类名中推断，因此这实际上不像方法级别的注释那么重要)。

带有测试覆盖率报告的

• 比如[医]杜鹃。这也是文档，因为它表明您的测试涵盖了哪些内容，哪些没有。

如果需要，请注释复杂的测试或场景，但首先支持可读测试。

另一方面，我试图让我的测试为自己辩护。换言之：

[Test]
public void person_should_say_hello() {
     // Arrange.
     var person = new Person();
     // Act.
     string result = person.SayHello();
     // Assert.
    Assert.AreEqual("Hello", result, "Person did not say hello");
}

如果我看一下这个测试，我会看到used (虽然它在PersonTest.cs中是一条线索；)，那么如果有任何故障，它就会发生在SayHello方法中。断言消息也很有用，不仅用于读取测试，而且在运行测试时，更容易在GUI中看到它们。

遵循AAA风格的排列、行为和断言使测试本质上是文档本身。如果这个测试更复杂，您可以在测试函数的上面添加注释，解释正在发生的事情。和往常一样，您应该确保这些都是最新的。

另外，对测试名称使用下划线表示法可以使它们更加可读性，将其与以下内容进行比较：

public void PersonShouldSayHello()

这对于长的方法名称来说，会使阅读测试更加困难。虽然这一点往往是主观的。