《测试驱动的嵌入式C语言开发》——3.9节我们到哪里了

3.9　我们到哪里了
在本章里，我们开始了LedDriver的开发。LedDriver并不是什么复杂的例子，但对于表现TDD的机制和过程来讲，最好从简单的例子入手。
我们用一个测试列表来帮助驱动设计和满足驱动程序的用户要求。本章开始的几个测试产出了一个骨架的测试夹具和驱动程序代码。我们已经准备好给骨架上添加更多的肉了。
大概有些读者会很关心代码不完整的结果，只是完成了部分的实现。别发愁。不管怎样你也不可能同时做完所有的事情。我们在有序地而且增量式地增加并校验行为。我们一直在拖延，但在这里拖延并不是一个贬义词。
我们通过把LED的地址传入给驱动程序来断开驱动程序与硬件之间的依赖关系。这个设计决定使得我们有机会去仿冒驱动程序，允许它去截取以硬件为目标的数据位映射。
从某种意义上讲，TDD就像从湍急的水中踩着突出的石头穿过一条山中小溪。这条路径并不是完美的直线，正如后期调试式编程所表现出来的那样。但我们要在不湿鞋的情况下穿过小溪。后期调试式编程就像要一次性的跳跃来飞过这条小溪。如果小溪很窄，这可能行得通。但更多情况下的结果是我们掉在溪水中要与意料之外的暗流缠斗才能到达目的地。每个测试都把代码一点点地引向完成的目标，如图3-3所示。TDD曲折的路线风险更小，因为代码总是能通过现有已经定义的测试。因软件bug而阻碍我们进程的风险更小些。我们正在通过小溪的半路上。我们将在第4章中走完剩下的路。