前几天,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 的方式重构出私有方法,以及用测试驱动重构处理遗留代码的方式,更多细节请阅读原文。
评论