覆盖软件项目的一套严格的单元测试提供两个巨大的好处：

他们可以是文档化的。

诊断Java代码: 在规范钢丝上行走(3)

它们加速了重构过程。

单元测试与静态类型类似，是文档的 可执行形式。因为单元测试理想地覆盖了实现的所有方面，也因为它们用简单的方式调用了功能以确定其是否正常运行，正在加入项目的或开始维护某些代码的程序员只要通读单元测试，就能够容易地确定各种功能组件的用途。

许多人在第一次听说单元测试可以是文档这一概念时，会表示怀疑：“怎么能用编写程序的同一语言来编写它的文档呢？”但是这个问题忽略了代码文档。

不应该用代码来说明代码的行为。代码本身已经说明了这个问题。相反，文档应该说明代码块 为什么要做它所做的事。任何读代码的人应该早已熟悉用来编写这些代码的语言 ― 如果他们不熟悉，则任何语言的文档也未必能帮得上忙。

但代码块是如何与程序其它部分交互的，这一点并不总是很清晰，这就是文档所要说明的。因为代码的读者熟悉（或者应该熟悉）编写它的语言，所以用与代码相同的语言来说明代码背后的意图就很有效了。

还有，单元测试加速了重构的过程。当一套单元测试可以在任何时间在代码上运行以确定是否有功能损坏时，程序员可以比在其它任何情况下更有信心重构代码。所引入的绝大多数错误可以被立即检测出来。

由于这些原因，想要编写健壮的软件，单元测试是一个有力的手段。实际上，因为单元测试充当了一种形式的文档，而且可以自动强制执行（通过将它们包含在构建过程中），所以将测试本身当作系统规范使用的建议听上去很有诱惑力。

用测试形成规范的 一部分是合理的，因为我们要让所有有效的实现通过全部系统级别的测试。但是用单元测试形成整个规范有一些严重的弊端。

首先，系统的测试集必然是不完整的。无论我们为一个系统指定多少测试，总会有一些系统输入和状态是我们所没有提供的。我们可以将测试解释为指定它们“最合理”的范围，但这种范围是模棱两可的。

此外，单元测试本质上是强制执行特定实现的特性。系统的实现方法有多种而不仅是一种。因此，将单元测试用作规范和将特定实现用作规范具有许多相同的缺点。

因此，我们最好将单元测试看作是规范的补充，而不是整个规范。

收益可以超过成本

我希望能够帮您形成这样的结论，在设计软件系统时需要拥有尽可能精确的规范，并能够认识到在形成这个定义时，极端编程模型规范的模块化构造能够平衡成本和收益。

还有，我希望自己已经充分阐述了将实现误作为规范的缺陷，并指出了过分依赖单元测试，希望它完成整个规范定义的侥幸想法所存在的问题。

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!