为什么要单元测试？

今天又和人争论了下什么情况下要单元测试。他的意思是单元测试是锦上添花的，有时间了做一下，没时间了就舍弃，与其花时间做单元测试，不如花更多时间在集成测试上。持有这种观点的不在少数，如果单元测试仅仅是这样的作用，我们真没必要搞什么TDD，直接集成测试不完了么？

软件必须测试，这个毋庸置疑。采用何种测试策略，根本上是从成本考虑。如何提高测试效率，降低测试成本，这是我们思考问题的出发点。那么，如果把时间大部分花在集成测试上，是否能节约成本？

大家都知道，集成测试需要的大量的准备工作。要有完整的测试环境、测试数据、测试人员。每次集成测试都要有大量准备工作，跑每一个集成测试的Case也要分为好多步骤。即使现在有了很多自动化的工具，在集成测试上花费的资源也还是比较大的。

再次集成测试是一种黑盒测试。测试人员只能从Feature的角度来了解软件工作情况，所以很难设计出覆盖情况很完整的Case。如果要很完整，又需要设计更多的Case，这样Case的设计和执行也会带来很大的成本。

所以，把大部分测试工作放在集成测试上，势必会增加软件测试的成本，进而提高整个软件成本，而不是减少。

而单元测试则不同。测试人员就是开发人员，测试对象也仅仅是很小一块逻辑代码，他对代码的内在逻辑是清楚的，也就是所谓白盒测试。借助于工具的帮助，开发人员可以很容易模拟各种接口的输入、验证输出。从而在不依赖任何外部环境的情况下对逻辑代码进行验证。

单元测试运行的成本也很低，一般的单元测试，只需要几秒钟就能跑上百个测试用例，而且可以由持续集成环境自动跑。这样的运行成本几乎是0，只有前期编写的一次成本。而且单元测试对业务逻辑代码覆盖率高，Case比较精准。

综上所述，单元测试成本低，集成测试成本高。那么成本低的我们应该多用，成本高的我们应该少用，这样总成本才低。当然，我这里不是否认集成测试和协议测试等的价值。只是对于成本高的测试，我们应该尽量减少使用频次。如下图：