使用测试驱动开发(TDD)方法，即整体敏捷模型驱动开发(AMDD)方法的一部分，您的测试有效地成为基于即时(JIT)创建的详细规范。不管喜欢与否，大多数程序员都不阅读系统的书面文档，相反，他们更喜欢使用代码。这没什么不对的。当试图理解一个类或操作时，大多数程序员首先会寻找已经调用它的示例代码。编写良好的单元/开发人员测试正是这样做的—它们提供了功能代码的工作规范—因此单元测试有效地成为技术文档的重要部分。类似地，验收测试可以成为需求文档的重要部分。当你停下来思考的时候，这是很有意义的。您的验收测试准确地定义了涉众对您的系统的期望，因此它们指定了您的关键需求。

测试驱动的开发(TDD)

图1的UML活动图中概述了测试优先开发(test first development, TFD)的步骤。第一步是快速添加一个测试，基本上只需要足够的代码就可以失败。接下来运行您的测试，通常是完整的测试套件，尽管出于速度的考虑，您可能决定只运行一个子集，以确保新测试确实失败。然后更新函数代码，使其通过新的测试。第四步是再次运行测试。如果它们失败了，您需要更新您的功能代码并重新测试。一旦测试通过，下一步就是重新开始。

图1所示。测试优先的开发(TFD)。

我喜欢用这个简单的公式来描述TDD:

TDD =重构+ TFD。

TDD彻底改变了传统开发。当您第一次实现一个新特性时，您要问的第一个问题是，现有的设计是否是使您能够实现该功能的最佳设计。如果是，则通过TFD方法进行。如果没有，则在本地重构它，以更改受新特性影响的设计部分，使您能够尽可能轻松地添加该特性。因此，您将始终提高您的设计质量，从而使它更容易在未来的工作。

与其先编写函数代码，然后再编写测试代码，如果您真的编写了测试代码，那么您应该在编写函数代码之前编写测试代码。此外，您可以通过非常小的步骤来完成—一次测试和少量对应的函数代码。采用TDD方法的程序员拒绝编写新函数，直到第一个测试失败，因为该函数不存在。事实上，在对代码进行测试之前，他们甚至拒绝添加任何一行代码。一旦测试就绪，他们就会执行确保测试套件现在通过所需的工作(您的新代码可能会破坏几个现有的测试以及新的测试)。这在原则上听起来很简单，但是当您第一次学习使用TDD方法时，它需要严格的规程，因为不首先编写新的测试，很容易“滑倒”并编写功能代码。

测试作为需求

图2描述了一个客户验收测试描述(为了简洁起见，它被缩短了，需要使用更多的步骤来扩展，以真正验证所描述的功能)。正如您所期望的，测试有设置和运行它的说明。此外，还显示了描述、测试ID(可选)和预期结果。验收测试应该是完全自动化的，这样您就可以将它们作为应用程序的回归测试套件的一部分来运行。FITNesse测试框架是这样做的一个流行选择。

图2。用于验证业务规则的验收测试。

设计规格测试

类似地，开发人员测试可以构成详细设计规范的大部分。开发人员测试通常使用xUnit开源工具家族编写，如JUnit或VBUnit。这些测试可用于指定应用程序代码和数据库模式。

测试是否有足够的文档?

很可能不会，但它们确实构成了其中重要的一部分。例如，您可能会发现仍然需要用户、系统概述、操作和支持文档。您甚至可能发现，您需要摘要文档来查看系统支持的业务流程。当您以开放的心态处理文档时，我怀疑您会发现这两种类型的测试涵盖了开发人员和业务涉众对文档的大部分需求。此外，它们是AM的单一源信息实践的一个很好的例子，也是您在文档方面保持尽可能敏捷的整体努力的一个重要部分。

原文：http://agilemodeling.com/essays/executableSpecifications.htm

本文：

讨论；请加入知识星球或者小红圈【首席架构师圈】