在进行GJB5000评价的时候，常常会听到这样的问题：
单元测试和集成测试能不能裁剪啊？
希望裁剪掉单元测试的那些单位理由几乎一样：
我们的软件规模小；单元测试的代价太大，我们没有资源；我们的工期很紧的……
从这些理由可以看出，希望不做单元测试的，都只看到了单元测试的成本，却丝毫不关注单元测试能给我们带来什么收益。
单元测试能给我们带来什么收益？它可以让我们降低测试成本、缩短工期。
为什么这么说呢？
软件开发中有一条重要的定律叫规模代价平方定律。这个定律如下：
定位并修复一个BUG所需的代价正比于目标代码规模的平方
比如：如果一个20行的函数刚写完时作者就能发现BUG，找到并修复这个BUG可能只需要1分钟；如果是在200行的一个类中，别人调用时发现BUG，阅读代码并定位问题可能就需要一个小时，对这个问题的修复以及重新代码评审又要花一个小时；如果在系统和系统联调的时候才发现这个问题，前面扯皮加定位问题就要半天时间，修改完成后重新验证、回归又是半天……
因为单元测试能够尽早在尽量小的范围内暴露错误，所以在整个项目开发过程来看，做好单元测试是能够带来降低成本、缩短工期的好处来的。
是否做单元测试，应当在衡量付出的成本和带来的收益之后才能做出合理的决策。
实际上，不同的项目类型对单元测试的要求也会有很大的区别。
新开发软件
此类软件大多数代码是新编写的，代码中潜伏BUG几率极高，通过单元测试带来的收益会超出投入的成本，这类软件应开展单元测试。
构件开发软件
这些软件是基于可重用构件进行开发的，可重用构件是成熟的、经过验证的，这类软件无需单元测试。
开发原型软件
这类软件往往是用户对软件的需求不明确，通过开发出来的软件原型的演示和使用，帮助确定软件需求。这类软件重视的是功能，而且追求快速实现，也无需单元测试。
COTS软件
这类软件的内部结构都是未知的，而且此类软件关注的也只是它的功能，所以，这类软件也无需单元测试。
而且，借助单元测试的过程资产积累以及部署自动化单元测试，可以进一步降低单元测试的成本。这意味着我们可以更多地获取单元测试的收益。
这正是：
单元测试可选择，权衡利弊做决策
切忌一笔糊涂帐，只畏困难不想做
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理
