有人说“TDD(测试驱动开发)可以带来优秀的设计”,也有人说“TDD 会对设计有负面影响”。如果有个具体例子的话,讨论起来会实际得多,所以下面我们来看一下私有方法以及它与优秀设计、可测试性的关系——这种对立观点的一个实例。
Szczepan Faber 在博客中写道,私有方法是一种反模式:
自从 TDD 诞生之日起,私有方法似乎就有了坏味道。被测试浸染的开发者总想寻找测试私有方法的办法。嗯……这显然是很困难的,所以问题就从“如何”变成了“为何”:为何要测试私有方法?大多数 TDDers 都会立刻回答说:别这么干。于是 TDD 又改变了我们构建软件的方式,对私有方法进行了重新评估
Jay Fields 在博客上描述了在 ruby 中测试私有方法的一种通用方式:
……我很少测试私有方法。我更倾向于通过 public API 来进行测试。不过偶尔也有这种时候,如果你可以给一两个私有方法写点测试用例的话,日子就可以过的容易一些。
Michael Feathers 在去年的 The Deep Synergy Between Testability and Good Design 一文中指出,TDD 可以带来优秀的设计,而反过来想,那些不可测试的代码应该引起我们的深思:
在我编写测试时,如果觉得有强烈的冲动促使我去测试一个私有方法,我就会把它看作一种暗示。它告诉我,我的类已经被封装得趋近于封闭了,测试代码无法再通过公共接口来“理解”这个类的行为。我顺从了这个暗示的召唤,重新构建了代码。通常我都会把这个私有方法(可能还有一些相关的方法)挪到一个新的类里面,在那里它不再是私有,可以让测试代码访问。
以上种种想法,都倾向于不鼓励使用私有方法,在天平的可测试性一端加入更多砝码。但它们并不是唯一的声音。实际上在我们所能看到的有关面向对象开发的观点中,很多都是支持少用一些类,极尽所能使用封装。在 public API 中只暴露最小的 API 集合,就会将耦合降低到最小。David West 在 Object Thinking 一书中,引用了 Lorenz 和 Kidd 在 Object Oriented Software Metrics 书中的论述:
- 一个应用程序应该最多包括 40 个故事,100 个类。
- 应用程序所属的整个业务领域不应该需要超过 1000 个类来完成。
- 每一次迭代后都该扔掉 25-30% 的代码。
- 每个类的职责:平均是 7 个。
- 每个类的方法数:平均是 12 个。
- 每个方法的代码行数:平均是 15 个。
- 需要进行注释的代码行数百分比:60。
- case 语句的数量:平均为 0。
如果私有方法确实是坏味道,需要把它们挪到自己所应归属的类中,这不就是“为了让测试变得简单,而增加类的数量”么?它势必会造成类的数量急剧膨胀。
那么该拿私有方法怎么办呢?测试它们太折磨人了。我们可否修改一下,把它们暴露给测试代码?或者不去测试私有方法,让设计与可测试性永不相干?或者,私有方法是一种坏味道,它表明一个类做了太多事情?
查看英文原文: Private Methods, Test Driven Development, and Good Design
评论