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

Question

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

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

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

Answer 1

我的主观观点：

• MEF看起来像一个非常好的插件框架;它不是一个完整的DI框架。如果您不需要实时可交换组件，请调查full DI/IoC Container frameworks。 Unity是Microsoft的替代方案。
• 确保您 执行Service Locator anti-pattern。尽可能使用构造函数注入接口。见great post by Mark Seemann和this one by Jimmy Bogard。您声明“尽可能利用容器”是一个问题 - 很少有类需要知道关于容器的任何。
• 获得一个非常好的模拟/隔离框架并学习如何使用它。我爱Moq。尽可能在被测系统上进行状态验证，而不是对模拟进行行为验证。
• 阅读The Art of Unit Testing。阅读有关单元测试的其他书籍和文章。练习TDD。继续学习。
• 阅读Clean Code并确保您的课程遵循SOLID原则（尤其是Single Responsibility Principle）。冗长的模拟设置是代码气味;你的课程可能做得太多了。高代码覆盖率很好，但更好的指标可能是cyclomatic complexity。
• 不要担心您的单元测试需要比生产代码更长的时间。但是，请将您的测试视为生产代码，并在保留可读性和可维护性时删除重复项。

Answer 2

以下是关于DI的一些很好的链接以及您可能想要检查的良好设计实践（在编写可测试代码方面）（谷歌技术讲座）：

• Clean Code Talks - Don't Look For Things!
• Clean Code Talks - "Global State and Singletons"
• Clean Code Talks - "GuiceBerry"

我发现它们对可测试设计有很多好的建议非常有帮助。