单元测试 vs. 私有方法

前几天，Naresh Jain 在 Managed Chaos 上发了篇博客，总结了一些测试中的 bad smell 。例如：

一个方法中有太多 test case——被测试的方法做了太多事情。
太多的 setup/teardown——表示被测试类的耦合性太高。
改变一个地方，多处测试受影响——也许是测试的设计问题，也许是实现代码中有过多依赖。
测试上下文中有太多依赖——设计中的耦合性太高。
测试运行速度缓慢——表示你的单元测试也许在使用外部系统，例如网络、数据库、文件系统等等。通常也意味着被测试类有过多的职责。
……

里面还有一条：

为了测试的目的，把成员变量或者方法的访问权限变成 protected 或者 public——可能是因为测试代码跟被测试的代码耦合太高，也可能是本来私有的东西有太多行为，这种情况下应该考虑把它抽出来作为独立的对象。

怎么为私有方法写单元测试？这个难题由来已久了。

有人会选择跳过私有方法，有人会选择去掉 private 限定符；跳过私有方法自然不是良策，但提升访问权限也会破坏封装，在 Naresh Jain 看来也算得上是 bad smell，那怎么解决才好？

Naresh Jain 对此语焉不详，不过还好， Agile Tips 在 08 年 11 月有一篇文章介绍了怎么测试私有方法。文末作者说道：

应该为私有方法添加测试么？我的答案是，在成功的用了 TDD 或者测试驱动重构（Test-Driven Refactoring）以后，你的代码中就不会出现针对私有方法的测试。

如果你用 TDD 编写全新的代码，在没有测试之前是没有功能的。私有方法是到了重构那一步的最后才会出现。把代码转移到私有方法中的这个过程，已经被先前写过的测试覆盖到了。所以，如果你成功了用了 TDD，代码中就不会出现针对私有方法的测试。

如果你在改善遗留代码，你就该使用测试驱动重构。这样的话，可能会临时针对私有方法写一些测试。但是，随着测试覆盖率的增加，那些 public 方法的测试会覆盖到所有的路径，也包括了私有方法的调用。所以，你也不再需要测试私有方法。

在文中，作者也举了一些简单例子说明了用 TDD 的方式重构出私有方法，以及用测试驱动重构处理遗留代码的方式，更多细节请阅读原文。