TDD 概要
“红灯-绿灯-重构”是TDD的支柱，将TDD过程分解为可重复的短暂周期。</br> 我们编写一个测试，确定它不能通过后，编写刚好能让它通过的实现代码，然后运行所有测试，并进入绿灯阶段。</br> 编写代码后不断对其重构，直到其质量到达我们期望的程度。</br>在这个阶段，测试应始终能够通过。</br> 在重构阶段，既不能引入新功能，也不能编写新测试。</br> </br> TDD首先是一种更佳的代码设计方式，而测试只是副产品，用来不断核实应用程序确实像期望的那样工作。</br> </br> 使用测试替身可避免使用外部依赖，如数据库、文件系统、第三方服务等。</br> </br> 鉴于只有代码能够准确而实时地呈现当前开发的应用程序， 因此，你想更深入地了解某段代码的作用时，首先应求助于使用TDD编写的规范（也是代码）。</br> </br> 使用TDD时，不用预先定义设计，相反，不断编写并实现规范的过程中，设计通常会变得清晰。</br> </br> TDD并非只适用于小型单元（方法），它也可用于更高层面。</br> 这些层面专注于功能或行为，可能横跨多个方法、类乃至应用程序和系统。</br> 在这些层面，使用的TDD是行为驱动开发（BDD）。</br> 不像TDD那样基于由开发人员为开发人员编写的单元测试，BDD可供组织的任何人使用。</br> BDD涉及的是行为，而且是使用自然（普通）语言编写的。</br> 因此测试人员、业务代表等都能参与其创建，还可将其作为参考。</br>