单元测试的思考

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

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

.WL+^o;R.b0　　2、怀疑派：单元测试很难实施，单元测试能力有限，无可能达到全覆盖，代码耦合太厉害无法测试。51Testing软件测试网o5NT!iB9E~[t N?

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

　　单元测试局限性的根本原因是它也是一种智力活动，用一个智力活动证明另一个的智力活动。智力活动的复杂性，随意性，和载体（人）的差异天然的决定他不是万能的，没有机械的那种重复性可靠精密。51Testing软件测试网"R)~;CAu'I(d

mw+}
W i]}a0　　单元测试很难实施的认识主要是对他的要求过高，这点上 .教旨派 和  怀疑派是一致的，你只能自己控制你的单元测试：51Testing软件测试网1eN@d a5mq`*qE

　　1、不是所有的东西都要测试51Testing软件测试网/t s2G\8U,S*c

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

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

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

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

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

-N2_6K'x4e2Eb0　　总之，单元测试要：51Testing软件测试网] jgE(Cn(w

　　● 简单

-Z/M#v?.yi W0　　● 迅速51Testing软件测试网*IE V!V1S^%gPC

　　● 迭代

o.f\5KkTU6A0　　只能做他擅长做的事。如果达不到，改善设计，达到这种程度。51Testing软件测试网0S,S_j%L