真正TDD
的好处是应用程序的实际测试,还是编写可测试的应用程序带来的好处?我问是因为我觉得谈话经常围绕着测试,而不是总的福利包。
6 回答
TDD 帮助您设计软件。测试变成了设计。通过首先编写测试,您可以从消费者的角度考虑您的代码,从而使软件设计更加用户友好和紧凑。
此外,通过应用 TDD,您通常最终会以可以提供测试模拟和存根的方式编写代码。这导致软件耦合度降低,随着时间的推移更容易更改和维护。
所以我想围绕 TDD 的讨论大部分都是关于测试的,但是这样做会带来其他很大的好处,例如质量(覆盖)、灵活性(解耦)、更好的设计(作为 API 的消费者思考)。
真正的改进在于它是一种迫使您真正思考设计和实现的好方法。然后,一旦您准备好测试并编写了代码,未预见问题的解决方案就会更容易出现。
经常发生在我身上的事情是一个很好的类比:当我要向论坛或 IRC 频道发布问题时,我喜欢把问题写得很好并且有充分的描述,很多时候是准备一个写得很好的和对问题的完整描述神奇地使解决方案出现。
TDD 的真正好处应该是它允许您修改/重构/增强您的应用程序,而不必担心您是否破坏了现有功能。编写单元测试往往会导致代码松散耦合和更好的架构这一事实不一定是 TDD 的重点,但我认为很难有一个没有另一个。
除非您拥有覆盖良好的单元测试,否则您无法真正体验到 TDD 的好处。为此,您将不得不编写可测试的代码。这就是为什么两者经常结合使用或相互替代的原因。
当您开发要发布多个版本的产品时,自动化测试可以节省时间并增强信心。通过自动化测试,您知道您没有破坏版本之间的任何内容。当您的产品是人们可以为其编写附加组件时,这尤其有用 - 您不想在版本之间破坏他们的附加组件。
使用 TDD,您可以在开发时获得一套很好的测试。如果没有 TDD,编写这些测试要困难得多。
Michael Feathers 有一篇富有洞察力的博客文章,题为“单元测试背后的缺陷理论”。说真的,去读吧。妙语是
所有这些技术都已被证明可以提高质量。而且,如果我们仔细观察,我们就会明白原因:所有这些都迫使我们反思我们的代码。
但是您应该阅读全文以了解上下文。
自动化测试使人类无法完成机器的工作。
测试驱动开发最大化了自动化测试的数量。
当然,超过某个点,仍然需要人类。当您尝试应用 TDD 超出该点时,您会达到收益递减。