关于TDD

 

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。

如果私有方法确实是坏味道，需要把它们挪到自己所应归属的类中，这不就是“为了让测试变得简单，而增加类的数量”么？它势必会造成类的数量急剧膨胀。

那么该拿私有方法怎么办呢？测试它们太折磨人了。我们可否修改一下，把它们暴露给测试代码？或者不去测试私有方法，让设计与可测试性永不相干？或者，私有方法是一种坏味道，它表明一个类做了太多事情？