本文是个人总结摘记，部分文字摘自其他大神博文等，如有雷同，未列参考文献，请见谅；
定义
- TDD，即测试驱动开发，强调的是测试先行。根据对业务理解，先写一些测试（E2E，Integration, Unit），此时得到运行结果为红色（测试运行失败），然后编写业务代码让其变绿（测试运行成功）。
- TDD目标：让代码更简洁；
形式
- 先分解任务，分离关注点，列Example，用实例化需求，澄清需求细节。
- 思考如何测试，所需的类、接口、输入和输出。
- 编写足够的代码使测试失败（明确失败总比模模糊糊的感觉要好）
- 编写刚刚好使测试通过的代码（保证之前编写的测试也需要通过）。
- 运行并观察所有测试。如果没有通过，则现在解决它，错误只会落在新加入的代码中。
- 如果有任何重复的逻辑或无法解释的代码，重构可以消除重复并提高表达能力（减少耦合，增加内聚力）。
- 再次运行测试验证重构是否引入新的错误。如果没有通过，很可能是在重构时犯了一些错误，需要立即修复并重新运行，直到所有测试通过。
- 重复上述步骤，直到找不到更多驱动编写新代码的测试。
好处
- 从宏观把握 Scope，开发人员不会在开发的过程中扩大或偏离 Scope。举个例子，开始一个功能点时，一上来添加一个 E2E 测试，整个 Scope 在此时就被框定，然后再细分到内部实现，最终以通过这个测试来完成这个功能。
- 提高代码的设计。当我们先写测试的时候，就会考虑到被测试的对象要尽可能被方便的测试，此时我们会尽可能的改良我的的 API 设计，以便利于测试，这样一来，我们写出的代码更具有可测试性，这样的代码往往具备较高的质量。
- 确保功能不会被遗漏。我们一开始更多关注的是业务，而不是代码的实现细节，此时写出来的测试会更全面的涵盖不同的 Case。
