由于测试先行，并达到足够的覆盖率，确保代码都经过了测试，有利提高代码质量。 TDD产生的测试就是对系统的一套完整的说明文档， 还能够产生一组完备的测试套件，这让团队可以更加自信得去进行代码重构。同时大大提高回归测试的频率，同时减少所花费的时间，避免产生冗余的，没有用的代码，减少对代码 Debugging 的时间。 将一个功能分解为一个个可以测试的更小单元，能够产生更小的，更清晰的，更加责任明确的类，更加松耦合的组件和清晰的接口。
ATDD是TDD的变种，TDD是基于单元测试的，而ATDD面向用户验收测试的。 在准备实施一个功能前，首先定义出期望的质量标准和验收细则，以及明确且达成共识的验收测试计划，以此来驱动开发人员的TDD实践和测试人员的测试脚本开发。对开发团队来说，ATDD 是由外向内，多方介入的，基于拉动策略的，并行开发测试方法；确保所有交付的产品都经过了充分的测试。
另外，BDD是TDD的补充，更适合高级别的业务需求和验收标准。通过用户故事定义需求，BDD定义的用户故事可以作为开发过程中的统一标准，促进开发人员、测试人员及用户共同协作。Cucumber 是一个BDD自动化测试框架，提供了对自然语言定义行为及步骤的支持。在执行用例时，会通过行为和步骤定义自动调用步骤定义内的代码运行。同时，提供了良好的断言机制，当执行失败时，可以清晰的看到测试用例的执行步骤，明确失败原因。
事情都有两面性，没有银弹。TDD产生的代码质量取决于测试的质量，不正确的测试会产生错误的代码，业务场景覆盖不充分的测试液会产生功能不完整的代码。更重要的是，TDD只适用于输入输出明确的开发项目，不适用于某些探索性的，输出不确定的开发，比如人工智能，安全等领域的研发。 另外在某些环境，TDD实施会有一些困难，例如异步通信等，需要一些额外的辅助工具，增加了复杂性。
也就是说，TDD不是万能的，不可能完全依赖TDD来提高质量。它既无法替代集成测试、性能测试等，也不能让程序没有bug。关键一点，TDD不适合所有项目，要求需求必须足够清晰，对模型和依赖特别复杂的项目也不太行。
小结
No test， No quality！质量很多时候是产品存亡的关键因素，没有质量的产品很难说什么用户体验。作为一个程序员，要把质量思维融入到开发过程中，对测试做到胸中有数。
源自公众号 喔家ArchiSelf