测试驱动开发:概述

我们寻求遵循敏捷哲学,但是我不确定如果您不进行TDD( 测试驱动开发 ),那么称自己(或您的团队)“ 敏捷 ”是否正确?

但是渐渐地,我逐渐意识到敏捷是一种哲学,而TDD是一种特定的方法论。 “保持敏捷 ”与坚持敏捷宣言的价值观和原则息息相关。 敏捷宣言文档中没有任何内容提到TDD,甚至没有提及单元测试

从那时起,我意识到无需进行TDD或单元测试就可以做到敏捷。 但这就是我对如何将敏捷作为一种实践以及将TDD作为一种方法的理解。 这是一种不太可能的观点,确实可以引发非常有趣的辩论,但就目前而言,我不希望偏离TDD讨论的主要主题。

为了以最简单的方式定义它,“测试驱动开发”是一种开发人员实践,涉及在编写要测试的代码之前先编写测试。 首先为尚不存在的代码编写一个很小的测试。 运行测试,自然会失败。 现在编写足够的代码以使该测试通过。 不再。

术语“测试驱动开发”似乎常常使人们感到困惑,这是否与测试或开发有关。 但是一旦开始做,您就会意识到,实际上这是在编写测​​试之前,只编写足够的生产代码来完成该测试和重构的一种做法。

一旦测试通过,请观察最终的设计并重构您看到的所有重复项。 这时很自然地认为设计太简单,无法处理此代码将要承担的所有责任。与其添加更多的代码,不如以下一个测试的形式记录下一个责任。 运行它,观察它是否失败,编写足够的代码以使它通过,检查设计并删除重复项。 现在添加下一个测试,观察它是否失败,使其通过,重构,失败,通过,重构,失败,通过,重构,依此类推。

在许多单元测试系统中,当测试失败时,我们将结果打印为红色。 然后,通过时,结果将以绿色打印。 因此,我们通常将此循环称为red / green / refactor

它是如何工作的?

测试驱动的开发或我们现在将其称为TDD,围绕着一个简短的迭代开发周期展开,该迭代周期如下所示:

  • 在编写任何代码之前,您必须首先为您的代码编写一个自动化测试。 在编写自动化测试时,必须考虑所有可能的输入,错误和输出。 这样,您的思想就不会被已经编写的任何代码所笼罩。
  • 首次运行自动化测试时,该测试应会失败—指示代码尚未准备就绪。
  • 之后,您可以开始编程。 由于已经有一个自动化测试,因此只要代码失败,就意味着它还没有准备好,直到通过所有断言后,代码才能被修复。
  • 代码通过测试后,您便可以通过重构开始清理它。 只要代码仍然通过测试,就表示它仍然有效。 您不再需要担心会引入新错误的更改。
  • 用其他方法或要求重新开始整个事情。

TDD的目的

TDD是一项主要的设计技术,而不是一项重要的测试技术。 当然,在TDD期间开发的单元测试确实具有非常有价值的验证目的。 但是,他们验证代码正确性。 每个软件项目都必须通过其他级别的测试(例如验收测试和需求测试)来补充它们。 单元测试为更高级别的测试奠定了基础,并使他们能够更有效地专注于自己的真实目的。 在进行系统测试时,我不想因编码错误而停下来,而这正是TDD的帮助。

TDD还是针对程序员意图的验证工具。 像极限编程派生的许多其他技术一样,TDD提供了一种有趣的双重检查机制。 使用TDD时,每个程序员都会陈述自己的意图两次; 一次在单元测试中,一次在生产代码中。 只有它们匹配时,我们才会显示绿色条。

如果您只想验证,则不必进行TDD(尽管您需要其他一些东西来进行低级设计,无论是建模还是正式规格)。 在这种情况下,我仍然建议单元测试与代码紧密结合。 只写关于验证的单元测试更加简单,因为没有更多的设计决策可做。 当然,主要的缺点是您失去了极好的设计机会,并冒着编写无法测试的代码的风险。