在我的项目经验中单元测试地位一直比较尴尬，大体上有两类人：

　　1、教旨派：认为单元测试能解决所有的测试问题，认为单元测试可以替代其他测试。

　　2、怀疑派：单元测试很难实施，单元测试能力有限，无可能达到全覆盖，代码耦合太厉害无法测试。

　　单元测试自然不是银弹，“单元”这个限定词，限定了这种测试不是集成测试和开发周期中集成测试后面的各种测试，重点在单元，这个单元是，函数，类，接口，模块等相对独立的东西，只能保证（也不能完全保证这些东西的正确性，这也关系到你的单元测试的有效性）这些单元的正确性。它也是这一阶段，这种粒度下比较有效的手段。也有大量工具和理论以及社区的支持，实施比较方便。最重要一点，他可以重复使用，随着用例的增多，越来越完善。有效性会逐步提高，这是一个长线投资，短期不见得有太多收获。

　　单元测试局限性的根本原因是它也是一种智力活动，用一个智力活动证明另一个的智力活动。智力活动的复杂性，随意性，和载体（人）的差异天然的决定他不是万能的，没有机械的那种重复性可靠精密。

　　单元测试很难实施的认识主要是对他的要求过高，这点上 .教旨派 和  怀疑派是一致的，你只能自己控制你的单元测试：

　　1、不是所有的东西都要测试

　　我们不用去证明相对论，勾股定理，在程序中，我们默认标准库的东西都是正确的，经典算法也是正确的，stl中没有bug，我们简单的赋值，沿用的模块等等都是不需要再写单元测试的，那部分我们心里没底，我们基本知道，这部分我们可以写单元测试，有了bug，我们可以补个单元测试的用例。

　　2、不需要调用实际的模块

　　数据库操作，网络操作，进程通讯，串口通讯，我们只要mock objec，提高单元测试的执行速度和测试的简单性。

　　3、单元测试不会比实际代码还复杂

　　如果相反，你没理解问题域，或抽象程度不够，改善设计。

　　总之，单元测试要：

　　● 简单

　　● 迅速

　　● 迭代

　　只能做他擅长做的事。如果达不到，改善设计，达到这种程度。