Vanilla Pop：IT团队怎么样呢？我们可以用TDD来实施一次设计冲刺，然后看看情况吗？
Horst：我还是坚持我自己不赞成微测试的政策。不过，我很乐意让团队来自己决定如何才能向我交付功能和质量。
代码狗：我不相信TDD。你不能在写代码之前就先写好测试啊。你知道吗？没人会这样做。你想想，不过几周，就会回到老样子，我称之为错误驱动开发。我们调试代码的人就是这样做的。
架构师：我改变了。请教了专家，建议我尝试一下更为灵活的思维。我努力做得更好。不再强加观点给同事。让团队决定，而不是我自己命令他们。一首叫“Kumbiyah”的歌，我们都开始唱唱好吗？Pop是对的。他向我展示了一种方法，所以，我们需要做的就是开始实施。管理层希望我们带头，实现全部代码100%的微测试覆盖。副总已经签发这件事。会有个连续整合服务器来运行它们。我们只需要实施即可。这就是目前的规矩。好运哈。
Jose：（小声说）呃，灵活思维持续不到5分钟。
Junior Joe：（小声说）你认为那会是个新记录吗？
代码狗：啊，这不会发生的。我们不会真地那么做吧？那是质量控制的事情啊。
Jose：我不知道。Vanilla Pop之前的工作很出色。你看过这些测试没？
代码狗：呃…没有，那是Pop的东西呢。
Junior Joe：我觉得有点眉目了。我支持。
Vanilla Pop：谢谢。
架构师：Vanilla Pop和Junior的覆盖率有40%。这是一个小的也是新的单页应用。代码狗也在做TDD，按我的估计，下周我们可实现100%覆盖。我们努力前进吧，伙计们。
（时间过去了。）星期二，50%。星期三，60%。星期四，65%。星期五，85%。（继续前进！）星期一90%。
架构师：不错！我对代码狗的转变印象深刻。他抓住了TDD的精髓。实际上，他处理的代码块实现了100%的覆盖。我提议给他颁个奖。
代码狗：（吃惊了）哇，谢谢！
各位开发人员：（拍了拍代码狗的背。）
Junior：干得好！
Vanilla：很自豪能认识你。
Jose：对开发者来说很不错了。
Vanilla：他真地这样做到了。
Horst：这是什么情况？我这样滑动屏幕，为什么什么都看不见呢？
代码狗：（尴尬的样子）我知道这是什么情况。我会调试并修复的。
（关门了）
Jose：很奇怪。他的代码是100%覆盖的，却似乎是有错误一样。
Junior：也许是个整合的问题？我审阅了他的代码，并建议他在视图层停止调用I.O.。不大量使用虚构的对象，就没法进行微测试。
架构师：代码狗在哪里？我希望它能适当重构一下代码。他的代码过于占用网络带宽了。
Vanilla：他正在处理一些Horst发现的情况。
架构师：什么？不可能吧！他的代码有100%的覆盖，看看这些漂亮的代码覆盖报告。
Vanilla：是的，真是个奇迹。Junior，你能向大家展示下他的微测试吗？
Junior：啊，好的！
Vanilla：啊，天呐。图灵的魂魄都会为此震惊的。
Jose：你看看Pop？他不是一个像你这样有个性的开发者。
Junoir：你会认为他的50个微测试什么测试也没做吗？我没有理由不这么想？
Vanilla：这些测试是假的。
架构师：这人真不可思议！他只是假装在TDD！
Jose：哦，天呐。他居然这样做了。真是疯狂，搞砸了。天呐，糟糕极了！
解说：代码覆盖是分析了解团队的代码自动化进展的好方法。但是如果推进得过快，或是用政策来强制实施，就容易得到虚假的结果。代码覆盖测试工具能让我们了解测试运行的时候哪些代码被执行，但并不能告诉我们自动化的测试是否在起作用。设想一个针对两个数值求和的函数。如果测量代码覆盖时，函数被执行，那么就会有100%的覆盖，但是代码全覆盖并不意味着函数会返回一加一等于二这样的结果。
结对编程或者审阅测试代码可以避免造假。如果你要审阅代码，那么检查微测试代码比检查产品代码更重要。微测试规格体现了开发者的意图。如果微测试质量足够好，那么我们可以相信能通过测试的产品代码也是高质量的代码。
下一集，TDD和Stack Overflow的专家开发者。
