Cedric Beust（译注1）在近一篇blog中引用了我的几篇发贴，其中包括关于“junit邮件列表”，“测试覆盖率需达到90%以上才算是有效代码”，还有“如果没有这么高覆盖率的话，那一种非专业行为”（译注2）等。Cedric对此的回复是这样的：

　　那是有点极端了，不过也并非全盘错误。而这句话没能鉴别出来的是其实有太多种层次上的“非专业”。我都能想出一些比“发布未经测试的代码”来得更严重的情况。

　　错过了后期限
　　发布的产品未能全部实现用户所要求的功能。
　　未能发布
　　我认为发布低质量的产品是非专业的。
　　我认为发布你不知道质量是否低下的产品也是非专业的。
　　我认为除非测试过，否则你无法获知所发布的产品是否质量低。

　　后，我认为如果你没有足够高的测试覆盖率，你的测试不可能覆盖足够多的产品代码，因而你无法了解所发布的产品是否质量低。

　　能够保证产品发布在终期限前的关键在于，你确信即将发布的产品不是低质量的，而这需要足够高的测试覆盖率。

　　好，现在可以进入正题了。假如你没有完整测试过，但你敢打赌你的代码能够工作，而且大多数时候代码确实不会发生什么问题。要问我这样是不是够专业的话，我的回答还是“非专业”。

　　Cedric继续提到说：

　　有很多种可以去了解代码能否工作的方法：测试是一个；经过几千个客户几年的使用；一贯的成功发布；核心功能只出现少量bug也是一个。仅通过测试和代码覆盖来了解代码能否工作的说法是荒诞的。

　　我不知道为何Cedric会认为让成千客户来测试你的代码是种专业行为。事实上，如果代码只产生非常少量的bug到是不错的，不过请告诉我多么的人才能写出这样的代码。而如果发布给客户的产品未经过高覆盖率测试，那程序员们要冒很大的险，这是非专业。

　　后，Cedric提到在测试过、确信能工作的代码和没测试过、不确信能工作的代码之间有一片中间地带。如下：

　　有这么一种称作“未测试但能工作的代码”处于中间地带。

　　我承认未经测试的代码也许可以工作，然而，除非测试过了，否则你无法知道这段代码是否可以工作。而且实际上，你对代码能否运行的掌握程度是跟测试覆盖率的高低有关的。

　　现在我知道了，Cedric所作的测试量一定是到达了某种程度，可能很多，也可能几乎全部吧。希望如此。现在我可以开始关心于测试完成之前发布产品的问题了。产品发布的终期限比质量更重要，你好在更多功能和质量之间选择前者。

　　后，令我堪忧的是认为达到高测试覆盖率和能够按时发布完备功能的产品之间是相互矛盾的见解。我认为按时发布功能完备的产品的佳方法是尽可能的消除在调试和让系统能够连贯运行（译注3）中所耗费的时间。而消除它们的方法是编写测试，并且在一开始编写它们。对于避免调试所浪费的时间的好方法是避免使代码暴露于测试的覆盖之外。

　　译注：

　　1，Cedric Beust，是WebLogic Server团队的高级软件开发人员，他在其博客Otaku中提出了J2EE、Java、AOP和软件开发等方面的见解，此外，Cedric更是敏捷技术的活跃分子。

　　2，详情参见“敏捷人还没接受它么”一篇帮助理解。

　　3，详情参见“TDD的三条军规”一篇帮助理解。