我注意到，当我进行 TDD 时，它通常会导致大量的接口。对于具有依赖项的类，它们以通常的方式通过构造函数注入：
public class SomeClass
{
public SomeClass(IDependencyA first, IDependency second)
{
// ...
}
}
结果是几乎每个类都会实现一个接口。
是的，代码将被解耦，并且可以很容易地进行单独测试，但也会有额外的间接级别，这让我感到有点……不安。感觉有些不对劲。
任何人都可以分享其他不涉及如此大量使用接口的方法吗？
你们其他人怎么样？
您的测试告诉您重新设计您的课程。
有时您无法避免传递复杂的协作者，需要对这些协作者进行存根以使您的类可测试，但您应该寻找方法为他们提供outputs相反，您可以考虑如何重新安排他们的交互以消除复杂的依赖关系。
例如，不是提供TaxCalculator with a ITaxRateRepository（在期间访问数据库CalculateTaxes），在创建您的之前获取这些值TaxCalculator实例并将它们提供给其构造函数：
// Bad! (If necessary on occasion)
public TaxCalculator(ITaxRateRepository taxRateRepository) {}
// Good!
public TaxCalculator(IDictonary<Locale, TaxRate> taxRateDictionary) {}
有时，这意味着您必须做出更大的更改，调整对象生命周期或重组大量代码，但一旦我开始寻找它，我经常会发现低洼的果实。
有关减少对依赖项的依赖的技术的精彩综述，请参阅模拟消除模式 http://simpleprogrammer.com/2011/01/26/back-to-basics-mock-eliminating-patterns/.
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
