我们看另外一个案例分析，大家可能曾经有这么一个设备，也就是Zune30G，这是微软对于IPod的一个回应，Zune30G，它是存在一个问题，在2008年12月31号，昨天我和一些人谈过，你们也听说过这么一个故事。但是抱歉了我又说要一遍，在12月31号Zune就变成了旨在消耗电池的设备，因为它不能在用了，不能在播放任何音乐了，只是在不断消耗电池，如果你给他充电也是不断消耗电池，这里有两个问题，第一这是一年最后一天，在西方世界他们在庆祝自己新年的时候，大家会开很多庆祝，在最后一年的时候却不能用了，你不能看成简单的问题，最重要一天坏掉了，有一些人可能意识到了，这是一个只拥有闰年的最后一天，我们在这些问题上进行了研究。但是他们找到了这么一个函数，然后就看到这个问题出现了，究竟这个问题是说在1980年开始，然后他们就需要来计算这个年、日、月，所以说这些代码是独立的。

　　如果你对这个代码进行一些改变的话，你可能就能解决这么一个问题。我们可以看到，实际上在把这个代码进行一个重新检测就能够发现这些问题。我看了一下，这个代码也得到这么一个结论，我认为这个公式是正确的。但是，我认为我可能应该写一个测试才对，所以我做了这么一个测试。然后在线的一些平面当中，通过这种变化这个测试实际上是失败。第一个在这，是关于这个系统的时钟认为有多少天，2008年是闰年的最后一天。第二行就是生产的代码，第三行来检测检测结果是不是星期三。所以说最受欢迎的一种解决方案，他实际上变成2009年的1月0号，实际上这是一个假设的日期不存在。但还是一个Bugs，虽然不是一个开放的Bugs。

　　所以说我们应该怎么做呢？我们需要知道这些Bugs在哪，然后为他们写一个测试。如果在这个测试当中，我们能够发现这个Bugs就能够预防这个Bugs，现在你知道这个Bugs在哪吗？你直接可以把Bug取出来就可以了。那么，这给我们怎样的启示呢？这个启示就是，它的意义就是如果我们想为所有的东西写测试的时候，我们就要把所有的情况都考虑在内，立刻我们在做的一半的人就会说，好的可能我应该这么做。但是，却太难了。但是，只要有了智能一切都可以成为现实，我们可以测试有可能出现错误的问题。

　　那么对于程序员来讲呢？他知道这个闰年最后一天是特别，但是他还是犯了这么一个错误，在实践当中他虽然是知道特别一天，但是他不需要写前一天测试，和后一天的测试，闰年最后一天是特别，他需要写这么一个测试，因为他是写生产代码，在TDD当中你需要在生产代码之前就写这个代码，你才能真正能不能正确来使用。

　　在TDD当中我们遵循Uncle Bob's三条原则，他现在给我们三个方法好的建议，如果这个测试不能够使得你单位能够顺利的过，那你就不要写这么一个生产代码。所以说你可以说，让我改变这个代码，不行，你要想改这个代码要先写测试。第二条原则你不允许写任何的单元测试，除非他最后有可能出现失败，或者你写的这一个问题，比如说在C++，C语言当中会出现这样的情况，你要写足够的代码。第三部分是最困难的，除非你能够通过这一个failing unit才行，不见得放入你需要的所有代码。

　　大家如果昨天去过我的演讲，我这里再给大家介绍一下Satate Machine，用这张图给大家介绍一下不同的步骤。我们如何来帮助这个程序按照他应该走的程序走下去。世界上大部分的国家，他们都使用这么一项技术来进行编程，也就是DeBug，然后再进行程序的编程，这实际上不是所谈的一个理想，这里面有一个很大的问题。我们必须在这里边拿一个激光笔指一指，我们看一下左边这个，如果我犯了一个错误没有被发现，后来有人发现了这个错误，找到这个Bug，然后我们就需要看一下大家每天有多少专门找Bug的会议来发现这些Bug。或者我会问你花多长时间找到这些Bug，可以是5分钟，也可以是5年，也永远是找不到这些Bugs。

　　所以说实际上这种先进行调试，再进行编程的方法，在测试驱动发展是怎样的呢？我们都是人，所以我们会犯错，我们先发现这个测试，然后立刻的我们就知道了这么一个问题，我们就知道我们到底哪做错了，然后把它进行修复。所以说，原来调试这个问题就消失掉了。好的，在现实当中是这样的，不见得你还会有孩子的Bugs，但是很多的Bugs会立刻消除，单位就不会进入Bug表里面了。在TDD当中，我们先进行调试，我这里有效性强调太多了，但是我写所有的代码会更加有效率，我非常关注这些代码，如果你能够让我同时进行测试可能就没有这么有效率了，因为这是评论界这么说的。

　　那么在做好代码之后，他就做好了。真是这样吗？代码其实并没有完全的完成，我们需要找到这么一个通路，他是来通过调试的。我这里要在问一次，当然我不指望在你那里答案，但是我们需要调试花多长时间，我们还不知道，因为Bugs有可能藏在任何地方，我们也不知道。所以，这种TDD情况，它是一个研究的过程，我们这里有一系列需要进行测试的表，然后我们选择一次做一个测试。所以说，随着我们的发展，开发，我们可以把设计进行一个演进来解决当前的问题。当我们结束的时候，我们可以看到测试过的属性代码，这样不需要做太多的调试了。

　　我并不是说这里没有所有的调试过程了，但是这意味着什么呢？是不是写一个测试要花很长的时间呢？是不是就使得你的工作减缓了，我怎么能够让我的老板来支持我呢？我怎么能够让我的工程师来试这样的方法呢，如果我是老板的话？所以说这是双向的。

　　另外一个简单的模式，如果不是进行人工代码测试我来进行自动化的话？因为在人工的测试之后，我在做这种自动的测试，实际上他比人工测试有时候要多花两倍的时间。如果是这种情况的话，那我就会有一个可持续性的流程，如果是真的话，看起来好象花费更多时间和金钱，但是有一点没有考虑到，就是你过去没有做到的一些工作。

　　我们待会还要进行一些测试，把这些Bugs拿出来，我们不但要进行测试，还要保证我们产品质量，还有要保证一些有可能非常常见的这种产品的故障会减少，这是一种可持续性的方法。但是，对我们来讲不见得能用的上，因为我们这里有一个特殊的问题。我们有这种火警系统，还有家用自动化系统，还有银行系统等等，这些都认为是比较特别的问题，对我们来讲可能用不上。当然，这些问题是特别的，在这个会议当中你们大家可能有意识到，你必须要逐渐的适应这么一个过程。