3.7 测试驱动开发者的状态机
可以把TDD想象成在一个状态机（state machine）里工作，就如图3-2所示。在这一过程的每一步中，你只需关注解决一个具体的问题。首先，你要决定下一个增量的行为是什么并用测试表达你所期望的产出。然后你要满足编译的要求，也就是设计接口并让头文件和测试之间达成一致（有时你所选择的名字已经在其他地方用过了，你会在这一步中发现这类问题）。
在接口和测试之间达成一致后，预期会得到一个链接错误，之后就要增加一个骨架实现，但并不期望它是正确的实现。测试失败是一个好的信号，说明你的测试可以发现代码中的错误。如果你发现你本来预期得到一个测试失败但它却通过了，那可能表明测试中有错误。这在通过剪切复制上一个测试来写下一个测试时很常见。并且，在用Unity或者其他需要多个步骤来安装测试用例的自动化单元测试框架时，失败的测试会告诉你测试已经被正确地安装到测试容器中了。
一旦测试通过，你就知道你已经拥有了期望的行为了，但你的工作还没有完成。我们要留下干净的代码。当努力使测试通过时，做得乱一点没有关系。只是不要把这些很乱的东西留在那里——要对它进行重构。
为什么要做这些小的步骤？因为它们让我们每次都只关注解决一个问题。
