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

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

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

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

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

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

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

　　再说经验

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

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

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

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

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

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

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

　　再说想法

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

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

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

　　好，接下来在一个一个展开来说。

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

　　实践告诉我，单元测试是需要良好的设计来支撑的。一个耦合度很高的模块几乎没有办法进行单元测试。我曾经几次相对已有的代码进行一些重构来支持单元测试。最终都放弃了。因为对这些耦合度很好的模块的重构总是会引入一些不可预期的问题。最终投入都要远远超过我的预计。因此，我得出的经验是：单元测试需要在物理设计时期就思考所涉及模块的可测试性，为了可测试性，需要对设计进行一些调整。往往这种调整都会使设计更好。因为，耦合性和可测试性是成反比的，因此可测试性越高，也就证明耦合性越低。低耦合是目前大家已经公认的良好设计的标准。

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

　　我在开始推动单元测试的时候就详细的研究了Rhino.Mocks类库。当时也被它强大语法能力所折服。并且实际将该类库应用在了我们项目的单元测试中。可是，过了一段时间后，当我再次需要使用Mock对象的时候。我才发现，我自己写一个Mock对象的成本其实非常低。远低于学习 Rhino.Mocks抽象的语法的成本低。因此，我建议你除非能够确认你每天（至少每周）都要用到Mock对象。否则，建议不要使用Mock类库。

　　因为，Mock类库的接口设计往往和我们开发人员（尤其是静态类型语言开发人员）的思维方式不一致。一段时间不用这些类库的时候，你就会忘记他们抽象的语法。就需要再付出时间去学习他们的语法。但是，对于一些特定的测试场景，编写简单的Mock对象的成本本身就非常低的。往往5分钟就可以写出来自己用着很爽的Mock对象。

　　但是，不推荐使用Mock类库，不等于你不需要学习和了解Mock类库。因为学习他们的接口会对你自己设计Mock对象非常有帮助。