偶然想起@jeffz_cn在twitter上问：“私有方法真的不应该单元测试吗？为什么？我觉得有的组件只是逻辑复杂一些，因此会提取私有方法，并且测试这些私有方法的逻辑。如果把这些内容统统从外部“注入”，这样私有的逻辑变公开了……但是这样难道没有过渡设计的味道吗？”。

　　然后想起来我在项目中推动单元测试的经过。觉得还是应该总结一下比较好。

　　先说现状（下面的数据我现在无法核实，但是，应该和实际值误差不大）

　　我目前负责的项目，有代码200K+，控件产品，尤其是Grid控件产品的代码复杂度远比应用程序的产品复杂度高。因为功能级的耦合度很高。因此，我认为我的产品的复杂度应该相当于普通应用程序500K+的水平。

　　目前单元测试有1300+。这些单元测试主要是自5.1和6.0阶段引入的。对遗留代码的单元测试很少。这两个阶段添加和修改的代码应该在130K+。（呵呵，看到这里你一定觉得数据有问题。呵呵，确实看起来有问题。但是，细节这里不能多说了。）

　　目前的单元测试代码覆盖率应该在20%～25%之间。

　　目前单元测试集成在每日构建中。至今没有发现单元测试失败的情况。（这一点很费解，目前归结为狗屎运）

　　再说经验

　　1.单元测试应该在物理设计阶段进行规划，而不是完成代码后补单元测试。

　　2.Mock类库一般情况下是鸡肋

　　3.对已有代码编写单元测试的难度非常高

　　4.当单元测试很多的时候，组织和命名会比较有挑战。

　　5.目前很少遇到单元测试影响重构的情况。

　　6.单元测试对重构的帮助不如预期

　　7.目前的现状下，很多平台的限制，使能够单元测试的部分很少。

　　再说想法

　　1.单元测试可以作为开发Leader掌控设计的一种工具

　　2.单元测试可以帮助开发人员设计出更好的结构

　　3.单元测试不需要对private成员进行。