TDD 保证良好的代码

问题的核心在于一种误解。TDD 并不是一套直接影响你设计决策的技术，而是一套帮助你明确代码在何时、何种条件下、基于特定设计应该做什么的技术。它让你自由选择设计、期望的功能以及如何实现代码。

TDD 不会建议你选择长变量名还是短变量名。它不会告诉你是选择接口还是抽象类。你是应该将一个功能拆分到两个类还是五个类？TDD 在这方面没有建议。你是否应该消除重复代码？反转依赖？连接数据库？这些只有你自己才能决定。TDD 不会提供建议。它并不智能，无法取代你和你的专业知识。它是一个简单的过程，帮助你验证你的假设和想法。

在我看来，TDD（测试驱动开发）具有巨大的好处，但我们必须将其放在适当的背景中看待。它为我们的决策提供即时反馈，但将每一个重要的软件设计决策留给我们自己。

使用 TDD，我们可以自由地选择遵循 SOLID 原则编写代码（这将在本书的第 7 章 “驱动设计——TDD 与 SOLID” 中详细讨论），或者我们可以采用过程式、面向对象或函数式的方法。TDD 允许我们根据需求选择合适的算法，并使我们能够在实现方式上灵活调整。TDD 适用于各种编程语言和各种垂直领域。

帮助同事们理解这一点，可以让他们意识到 TDD 并不是某种神奇的体系，能够取代程序员的智慧和技能。相反，它通过为我们的决策提供即时反馈来增强这些技能。虽然这可能会让一些希望 TDD 能够从不完美的思维中产生完美代码的同事感到失望，但我们可以指出，TDD 给了我们思考的时间。它的优势在于将思考和设计置于核心位置。通过在编写生产代码之前编写一个失败的测试，我们确保了自己已经思考过代码应该做什么以及如何使用它。这是一个巨大的优势。

既然我们理解了 TDD 并不会为我们设计代码，但它仍然是开发者的好帮手，那么我们该如何测试复杂的代码呢？