自动化测试作为文档

编写自动化测试的理由之一是测试可以充当系统的有用文档。 但是测试记录了什么？ 谁会觉得本文档有用？

大多数开发人员不依赖系统文档，因为没有足够的文档来使他们完整地了解系统的工作方式，或者因为其中的太多内容无法阅读，或者因为它的编写不正确，或者因为它没有运行而已。至今，或者因为他们不相信它是最新的。

但是，一套很好的自动化测试可以告诉您该系统今天的真正工作原理，而不是有人认为它应该如何工作，他们认为应该如何工作，或者它曾经如何工作（如果有人不愿写下任何内容）。

“测试只不过是可执行文件而已。 在编写新代码时，应该由最接近该代码的人（即作者）进行记录。 这就是我进行开发人员测试的理由。

注释“ doc blocks”和Wiki页面在某种程度上总是不准确的。 相比之下，每当过期时，自动化测试都会发出很大的失败。 因此，在文档方面，自动化测试的独特优势在于（给定CI服务器），您至少可以选择在文档开始偏离现实时保持文档为最新。”

诺亚·萨斯曼（Noah Sussman）

如果……，您也许可以将测试用作文档。

要用作文档，测试必须是：

1. 全面的–他们必须涵盖系统代码和功能的所有重要领域；
2. 经常运行并进行工作–每次签入时都要运行一次，或者至少要经常运行一次，以使每个人都确信自己是最新的； 并且测试必须通过–您不能让测试失败或失败；
3. 为阅读而写–编写有效的测试和编写可用作文档的测试是两件事。
4. 在正确的抽象级别上，大多数人在谈论自动化测试时都意味着单元测试。 …

单元测试构成了随系统自然发展的设计文档。 再读一遍。 这是软件开发的圣杯，文档随系统自然发展。 与提供编码的用例集相比，记录类的更好的方法是什么。 这就是这些单元测试的内容：在一组受控输入的情况下，一组编码用例记录了类的工作。 因此，此设计文档始终是最新的，因为始终必须通过单元测试。

Jeff Canna测试，好玩吗？ 真？

当然，即使频繁运行并通过持续集成或持续交付的测试仍然可能包含错误。 会有通过但不应该通过的测试，或者告诉您系统做什么的测试，但是系统做什么不是应该做的（让开发人员编写测试的风险之一就是，如果他们误解了，要求并弄错了代码，他们也弄错了测试）。 但总的来说，经常运行的测试应该比某些文档的准确性更高，而某些文档可能一开始就正确，也可能从未如此。 通过代码覆盖率分析，您至少可以了解测试描述了系统的哪些部分，而没有描述了哪些部分。

必须编写测试才能读取

使用测试作为文档的一个问题是，测试只是达到目的的一种手段， 即使是预先写在TDD中的测试也是如此 。 测试只是开发人员用来编写代码的基础架构和工具的另一部分（而这全都与代码有关）。 测试是帮助开发人员考虑他们需要编写什么代码（如果他们遵循TDD），证明该代码能够实现预期功能以及在将来人们进行更改时发现错误的工具。

结果，开发人员不会像使用代码本身那样投入大量的精力和精力来设计和实施测试。 只要测试运行Swift并且覆盖了代码（或者至少覆盖了代码的重要部分），它们就可以完成工作。 无需过多关心测试的命名方式或内部外观。 很少有团队会进行同行评审单元测试 ，即使那样，大多数评审人员也只会检查看到有人编写了测试，而不是每个测试都是正确的，或者每个测试都有一个很好的含义和一致的名称并且易于理解。 很少有开发人员了解xUnit测试模式或花费额外的时间（或有能力花费额外的时间） 重构测试 。 因此，许多自动化测试并非整洁，一致或易于遵循。

使单元测试很难作为文档遵循的另一件事是测试的组织方式。 结构化和命名单元测试的通用约定是，开发人员将为系统中的每个代码类/模块编写一个测试类/模块，并使用测试方法来断言该代码模块中的特定行为。

假设编写代码的人编写了一套全面的测试，并遵循一致的，定义良好的结构和命名方法，并且为每个测试类和测试方法以及编写代码的每个人都提供了良好的描述性名称。随着时间的流逝，他们理解了所有这些内容，并在他们进行更改，重构代码并转移职责并编写自己的测试（假设很多）时费力地将所有内容保持不变，那么您应该能够获得一个好主意通过测试，了解每段代码内部发生的情况。

您真的可以从单元测试中了解系统吗？

但是您仍然无法通过阅读单元测试来阅读有关系统如何设计，系统如何执行或如何执行的精彩故事。

即使单元测试是完整的，最新的，编写得很好，组织良好并有好名声（如果，如果，如果，如果，如果是），那么通过查看所有这些测试而积累的详细信息将是压倒性的。 单元测试离金属太近，有时会被固定装置和其他测试管道遮盖，而与业务逻辑或设计的重要方面相距太远。

单元测试包括许多与故事没有直接关系的较低级流程的测试。

Steve Jorgensen，在单元测试中作为文档发表评论

测试遵循该代码。 不了解代码就无法理解测试。 那么，为什么不阅读代码呢？ 您最终必须这样做，以确保您真的知道发生了什么，并且因为没有阅读代码，就无法知道测试是否一开始就编写得很好。

低级开发人员测试可用作文档的一个地方是描述如何使用API ，前提是测试是全面，富有表现力的，并且“以其验证的行为显而易见的方式命名”。

像这样的一组很好的单元测试可以作为参考实现，显示应该如何使用API​​，并记录常用用法细节：

如果您正在寻找有关如何使用Rails API的权威性答案，那就不要错过Rails单元测试。 这些测试提供了出色的文档，说明了API支持什么，不支持什么，打算如何使用API​​，驱动API的用例类型和特定领域的问题，以及最可能使用哪种API在将来的Rails版本中。

Peter Marklund，Rails技巧：将单元测试用作文档

但是同样，这只有在您花时间设计，组织和编写测试以进行“双重职责”作为测试和文档时才有效，（ 双重职责：如何重新利用您正在做的单元测试以帮助创建单元测试。布莱恩·巴顿（Brian Button ） 撰写的不是您需要的文档 ，并使您的测试“对于尽可能多的不同读者来说，尽可能地人性化”。

测试为文档？

我喜欢将自动化测试用作文档的想法–我们所有人都可以通过这种方式节省时间和金钱。 但是，此文档是为谁准备的，应如何使用？

我不知道有任何开发人员会从阅读测试案例入手，以了解系统的设计。 一个好的开发人员知道他们不能信任文档或图片，测试，甚至其他程序员告诉他们的内容或代码中的注释。 他们唯一可以信任的是代码。

测试作为测试人员的文档可能更有用。 毕竟，了解测试以维护或添加测试是测试人员的工作。 但是大多数测试人员不会从大多数测试中学到很多东西。 当涉及到单元测试时，对于测试人员和开发人员而言都是相同的：除非您了解代码，否则单元测试就没有用。如果您理解代码，则应改为阅读它。 更高级别的验收测试更容易理解，对于非技术人员尤其有用。 通过高级功能和集成方案（ 大型胖测试 ）或在Fitnesse之类的工具中捕获的验收测试 ，讲述一个故事并关注一个故事，讲述一个系统的工作应该更容易。 这些测试没有断言特定于实现的特定条件，而是描述了技术场景，业务规则和业务工作流以及其他人认为足以进行测试的其他要求。

但是，即使您可以遵循这些测试，也没有办法不花时间与人们交谈，了解域，亲自测试系统以及……阅读代码，就无法知道它们对系统功能的描述程度。

我向乔纳森·科尔 （ Jonathan Kohl） （我认识的最聪明的测试人员之一）询问了他使用自动测试作为文档的经历：

在03和04年，Brian Marick和我一直在研究这个问题。 2004年，我们在XP / Agile Universe上与测试人员，开发人员和其他项目利益相关者举行了一个实验研讨会，以了解如果不熟悉程序代码（代码和自动化单元测试）的人可以从中获得有用的东西，将会发生什么情况。自动化测试作为文档。 这是一次彻底的彻底失败。 从文档角度来看，没有人从自动化单元测试中真正获得任何价值。 我们必须解释一下发生了什么……

经历之后，我和马里克（Marick）基本上放弃了这个想法。 我放弃了整个双重职责。 文档确实擅长于记录和解释，而代码擅长于程序的创建和执行。 我现在选择适合该工作的工具，而不是尝试重载概念。

最重要的是，我发现测试根本没有作为文档有用。 如果做得不错，当我不熟悉系统时，确实可以将它们用作实现接口等的示例，但是没有什么可以代替优秀的书面文档，尤其是在进行一些面对面的头脑风暴和解释时。

自动化测试有很多好处，尤其是当您拥有一套完善的自动化套件之后。 但是文档不是其中之一。

参考： Building Real Software博客的JCG合作伙伴 Jim Bird提供的自动化测试作为文档 。

翻译自: https://www.javacodegeeks.com/2013/06/automated-tests-as-documentation.html