使用OOD协调单元测试

Question

TDD现在风靡一时,越来越多的软件商店正在转向敏捷,scrum等.我当然可以看到自动化测试的优势,但我也看到TDD与良好的面向对象设计的某些原则相矛盾.

TDD要求您在代码中插入接缝,通过接口公开实现细节.依赖注入或协作者注入违反了信息隐藏原则.如果您的类使用协作者类,那么这些协作者的构造应该是类的内部,而不是通过构造函数或接口公开.

我没有看到任何文献解决编写可测试代码之间的冲突,同时坚持封装,简单和信息隐藏的原则.是否以任何标准方式解决了这些问题？

Answer 1

您认为实现细节的方法和类实际上是表示轴的接缝,您可以沿着这些轴来改变组件并将组件重新组合成新的星座.

关于封装的经典想法往往过于粗糙,因为当你隐藏很多移动部件时,你也会使代码非常不灵活.它也往往违反了很多SOLID原则 - 最突出的是单一责任原则.

大多数面向对象的设计模式往往是相当细粒度的,并且非常适合SOLID原则,这是适当的面向对象设计细粒度的另一个指标.

如果您的类使用协作者类,那么这些协作者的构造应该是类的内部,而不是通过构造函数或接口公开.

这是混合在一起的两种不同的东西.我同意在大多数情况下,协作者不应通过接口公开.但是,通过构造函数公开它们是正确的做法.构造函数本质上是类的实现细节,而接口提供真正的API.

如果要保留粗粒度API以定位默认功能,您仍可以通过提供Facade来实现.有关更多详细信息,请参阅此文章:依赖注入(DI)"友好"库

Answer 2

根据所讨论的语言，可以采取一些措施将 TDD 与 OOP 集成。在 Java 中，您可以使用反射来测试私有功能，并且可以将测试放置在同一个包中（最好在单独的源代码树中），以便测试包私有功能。就我个人而言，我更喜欢仅通过相关代码的公共 API 来测试功能。

我不知道关于这个主题的任何“官方”资源，尽管我知道Bob 叔叔已经就 TDD 主题撰写了大量文章，并且认为它与他的 OOP 的“SOLID”原则兼容。