《测试驱动的嵌入式C语言开发》——1.1节为什么我们需要TDD

1.1　为什么我们需要TDD
Zune是微软用来与iPod竞争的产品。如果使用测试驱动开发就可能阻止一个在Zune中令人尴尬的bug。2008年12月31日这一天，Zune变成了一块砖头。这个日子有什么特别的吗？那天是新年前夜，闰年的最后一天，也是30GB Zune经历过的第一个闰年。
很多人分析了Zune的这个bug，并且最终定位问题到时钟驱动程序中的一个函数。尽管下面的例子不是实际的那个驱动程序代码，但这段代码有着相同的bug。

很多代码阅读方面的专家在看过这段代码后得出了和我一样的错误结论。我们关注到了布尔表达式（days>366）。闰年的最后一天的确是第366天，但是在这里却没有得到正确处理。在闰年的最后一天，这段代码会进入一个死循环！我决定要为SetYearAndDayOfYear()写一些测试来看看把布尔表达式改成（days>=366）是否可以改正这个错误，就像90%的为Zune的这个bug写博客的人所预测的那样。
在把这段代码放入到自动化测试框架中以后，我写了如下的测试用例，它本可以挽救很多新年前夜的派对：

就像Zune一样，这个测试进入了死循环。在终止测试进程后，我把这个基于几千程序员评审得来的流行改法应用到代码上。令我吃惊的是，测试失败了，这是因为SetYearAndDayOfYear()认为这一天是2009年1月0日。新年前夜派对可以放音乐了，但还存在bug。现在bug更容易看出而且更容易改了。
有了这一个测试，Zune的bug本可以避免。一大群人评审代码后的结论很相似，但大多数人还是没能得到正确的解法。我不是在打击你对代码评审的信心，评审代码还是有必要的。但只有代码运行起来才是唯一能确认它正确的方式。
你会想，我们怎么知道要写这个测试？我们可以在任何有bug的地方写测试。问题是我们不知道bug在哪里——它们可以在任何地方。因此，这意味着我们不得不为所有的东西写测试，至少是为任何可能出错的东西。想象一下所有需要的测试，这有点耸人听闻。但不要着急。你不必为每一年里的每一天都写一个测试，你只需要为每一个关键的日子写测试就可以了。本书就是关于如何写这些测试的。本书将帮你学到该写哪些测试，如何写这些测试，如何去避免在你的产品中出现如Zune一样的bug。
最后，让我们回过头来回答“为什么我们需要TDD”这个问题。我们需要TDD，这是因为我们是人类，人类会犯错误。计算机编程是一项非常复杂的活动。除了其他原因，TDD还是自动化测试用例，通过它，我们系统地得到按我们的意图工作的代码，并且可以同时保持这些代码可工作。