早在2003年，Kent Beck和David Astels首先提出了测试驱动开发(TDD)的概念，作为开发项目代码的新方法。简单地说，这个概念假设对于开发中的每个步骤，只应该创建足够的应用程序代码来成功地完成给定的测试需求。开发人员从一个简单的测试需求开始并修改代码，直到测试成功。然后他们创建下一个测试，开发相关的代码并继续这个循环。随着流程的推进，开发人员将“重构”(重新测试)代码，以确保在将新测试合并到应用程序需求中时不会出现任何问题。
这听起来很好，但是我们如何在自动化应用程序中利用这个概念呢?
通常，我们的任务是将系统的需求定义为测试协议开发中独立的文档工作。这又与实际的代码开发分开。简而言之，这意味着我们可以开发需求，然后并行地开发应用程序代码和测试脚本。
这里正在进行大量的开发，但许多项目无法支持这样的工作所需的成本和时间。
通过在任何代码开发之前查看测试设计，我们消除了为代码创建需求的单独任务。更准确地说，我们将需求开发合并到测试协议中，最小化或消除创建规范的独特阶段。
简单地说，您通过指定将验证需求是否得到正确满足的测试来定义应用程序的需求——然后为该测试编写代码。您测试代码并修改它，直到它通过测试，然后继续进行下一个所需的测试。
实际情况是，在编写第一部分代码之前，您可能定义了许多测试，但您可以一次编写和测试一个。其中一些代码是多余的，特别是当您有一个经过验证的、高质量的代码库时。当您只编写了几行代码时，而不是在您编写了数百(或数千)行代码后进行测试，这样做更有效率。
这里的目标是在短时间内开发符合测试协议的干净代码，并提供足够的文档来开发、测试和验证应用程序是可靠的。许多客户很少或没有规格或要求，宁愿不购买设计文件。我们都见过这样的项目，期望的结果是“明显的”或“容易的”，并且只需要与所有者/最终用户进行几个小时的对话就可以进行下去。然而，我们总是需要一种方法来测试和验证客户端所开发的确实是他们想要的。
TDD的另一个优点是，它不仅适用于代码开发。您还可以使用它来定义和测试硬件实现以及单元和系统架构。最后，在开发任何代码、购买硬件或执行现场工作之前，您的测试文档和需求规范是相同的和完整的。
我建议您先在一个小项目中尝试这个方法，并验证您可以更容易、更快地开发文档和代码。你更有可能拥有一个成功的项目和愉快的客户!
杜安·格罗布是Avanceon的注册会员控制系统集成商协会(相)。欲了解更多关于Avanceon的信息，请访问其简介工业自动化交换．
