要不要做单元测试，这是一个选择题！

　　单元测试和集成测试能不能裁剪啊？

　　希望裁剪掉单元测试的那些单位理由几乎一样：

　　我们的软件规模小；单元测试的代价太大，我们没有资源；我们的工期很紧的……

　　从这些理由可以看出，希望不做单元测试的，都只看到了单元测试的成本，却丝毫不关注单元测试能给我们带来什么收益。

　　单元测试能给我们带来什么收益？它可以让我们降低测试成本、缩短工期。

　　为什么这么说呢？

　　软件开发中有一条重要的定律叫规模代价平方定律。这个定律如下：

　　定位并修复一个BUG所需的代价正比于目标代码规模的平方

　　比如：如果一个20行的函数刚写完时作者就能发现BUG，找到并修复这个BUG可能只需要1分钟；如果是在200行的一个类中，别人调用时发现BUG，阅读代码并定位问题可能就需要一个小时，对这个问题的修复以及重新代码评审又要花一个小时；如果在系统和系统联调的时候才发现这个问题，前面扯皮加定位问题就要半天时间，修改完成后重新验证、回归又是半天……

　　因为单元测试能够尽早在尽量小的范围内暴露错误，所以在整个项目开发过程来看，做好单元测试是能够带来降低成本、缩短工期的好处来的。

　　是否做单元测试，应当在衡量付出的成本和带来的收益之后才能做出合理的决策。

　　实际上，不同的项目类型对单元测试的要求也会有很大的区别。

　　新开发软件

　　此类软件大多数代码是新编写的，代码中潜伏BUG几率极高，通过单元测试带来的收益会超出投入的成本，这类软件应开展单元测试。

　　构件开发软件

　　这些软件是基于可重用构件进行开发的，可重用构件是成熟的、经过验证的，这类软件无需单元测试。

　　开发原型软件

　　这类软件往往是用户对软件的需求不明确，通过开发出来的软件原型的演示和使用，帮助确定软件需求。这类软件重视的是功能，而且追求快速实现，也无需单元测试。

　　COTS软件

　　这类软件的内部结构都是未知的，而且此类软件关注的也只是它的功能，所以，这类软件也无需单元测试。

　　而且，借助单元测试的过程资产积累以及部署自动化单元测试，可以进一步降低单元测试的成本。这意味着我们可以更多地获取单元测试的收益。

　　这正是：

　　单元测试可选择，权衡利弊做决策

　　切忌一笔糊涂帐，只畏困难不想做