在利用依赖注入的同时,通过设计考虑简化测试

Question

我们还需要几个月的时间才能重新设计产品的逻辑和业务层.通过利用MEF(依赖注入),我们已经实现了高水平的代码覆盖率,我相信我们拥有非常可靠的产品.由于我们一直在研究一些更复杂的逻辑,我发现单元测试越来越困难.

我们正在利用CompositionContainer来查询这些复杂算法所需的类型.我的单元测试有时难以遵循,因为必须进行冗长的模拟对象设置过程,恰到好处,以允许验证某些情况.我的单元测试通常比我试图测试的代码花费更长的时间来编写.

我意识到这不仅是依赖注入的问题,而且是整个设计的问题.对于我过于复杂的测试,是不是很差的方法设计或缺乏组合？我已经尝试过基类分析测试,创建常用的模拟对象并确保尽可能地利用容器来缓解这个问题,但我的测试总是非常复杂且难以调试.您已经看到哪些提示可以使这些测试简洁,可读且有效？

Answer 1

我的主观观点:

MEF看起来像一个非常好的插件框架; 它不是一个完整的DI框架.如果您不需要实时可交换组件,请调查完整的DI/IoC Container框架.Unity是微软的替代品.
确保您没有使用Service Locator反模式.尽可能使用构造函数注入接口.看看Mark Seemann的这篇精彩文章和Jimmy Bogard 撰写的这篇文章.您声明"尽可能利用容器"是一个问题 - 很少有类需要了解容器的任何信息.
获得一个非常好的模拟/隔离框架并学习如何使用它.我喜欢Moq.尽可能尝试对被测系统进行状态验证,而不是对模拟进行行为验证.
阅读单元测试的艺术.阅读有关单元测试的其他书籍和文章.练习TDD.保持学习.
阅读清洁代码并确保您的课程遵循SOLID原则(尤其是单一责任原则).冗长的模拟设置是代码气味; 你的课程可能做得太多了.高代码覆盖率很好,但更好的度量标准可能是圈复杂度.
不要担心您的单元测试需要比生产代码更长的时间.但是,请将您的测试视为生产代码,并在保留可读性和可维护性时删除重复项.