单元测试 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的方式重构出私有方法，以及用测试驱动重构处理遗留代码的方式，更多细节请阅读原文。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
