流程
TDD流程是一套最重要的实践。 </br></br></br>
先编写测试，再编写实现代码
【好处】这可确保编写的代码是可测试的，即每个代码都有为之编写的测试。</br> </br> 通过先编写或修改测试，开发人员将在着手编写实现代码前专注于需求，这是TDD与完成实现后再编写测试的主要差别所在。</br> 先编写测试的另一个好处时，可避免测试变成质量检查（而不是质量保证）的手段。</br> 我们要力图确保质量是内生的，而不是事后再去检查是否达到了质量标准。</br>
仅在测试失败后才编写新代码
【好处】这确认了在没有实现的情况下，测试不管用。</br> </br> 如果测试不要求编写或修改实现就能通过，则说明要么它测试的功能已经实现，要么测试本身存在缺陷。</br> 如果测试定义的新功能没有实现而总是能够通过，就说明它毫无用处。</br> 测试必须因预期的原因而失败，此时，虽然不能保证它验证了正确的事情，但能够确定验证本身是正确的。</br>
每次修改实现代码后，都再次运行所有测试
【好处】确保代码更改没有带来任何意料之外的副作用。</br> </br> 应使用持续集成工具从仓库提取代码，对其进行编译并运行测试。诸如：
- Jenkins（http://jenkins-ci.org/）
- Hudson（http://hudson-ci.org/）
- Travis（https://travis-ci.org/）
- Bamboo（https://www.atlassian.com/software/bamboo）
仅当所有测试都通过后才编写新测试
【好处】将始终专注于小型工作单元；实现代码几乎始终处于可运行的状态。</br> </br> “实现代码几乎始终像期望的那样工作”是TDD的目标之一。
仅当测试都通过后才重构
【好处】这样的重构是安全的。</br> </br> 大多数情况下，重构期间都不需要编写新测试——对既有测试做细微修改即可。 对重构来说，期望的结果是在修改代码之前和之后，所有测试都能通过。