我们可以在单元测试中使用多个模拟对象吗？

Question

我读过很多关于单元测试的文章。 大多数文章说我们不应该在测试中使用多个模拟对象，但我不明白为什么。 有时我们在测试中确实需要多个模拟对象。

Answer 1

根据上下文，您可以在单元测试中使用多个模拟。

但是我认为“文章”可能暗示的是

• 防止过度嘲弄。当单元测试模仿所有合作者时，你将门打开;当您替换真正的协作者时，该方案可能会失败。通过尽可能/尽可能地减少模拟的数量并使用真正的合作者，您可以最大限度地降低风险。
• 高耦合警告：如果您发现自己不得不模仿大量合作者来编写单元测试，那么它可能是一种设计气味，表明您有很高的耦合。

Answer 2

我不确定你所引用的是哪些文章，但我通常每个依赖项都有一个模拟对象用于被测试的类。

Answer 3

您应该根据需要添加尽可能多的模拟以隔离您正在测试的课程。对于不应该成为测试一部分的每个依赖项，您都需要一个模拟。

为了简单起见，有时你会在测试中放入两到三个类，因为它们构建类似于组件的东西并且高度耦合。其他一切都应该被嘲笑。

我知道这个“最佳实践”只有一个模拟而且也不理解它。在我们的单元测试中，我们有很多模拟，一些环境模拟是由我编写的测试框架设置的（例如，TransactionService，SecurityService，SessionService）。只有一件事需要考虑，正如Gishu在他的回答中已经提到的，许多嘲讽都表明了高依赖性。这取决于你什么时候太多了。我们有许多小接口，在测试中需要很多模拟。

要解决问题，您应该不在以下情况下模拟依赖关系：

• 它是被测试类的高度耦合的部分，如内部类，私有类等。
• 这是一个常见的.NET框架类，如Collection等，
• 您希望编写集成测试以准确测试与该类的交互。 （你仍然会模仿其他所有内容，你仍然可以隔离每个相关类的单元测试。）
• 模拟某个类只是昂贵的。小心决定它太昂贵，模拟似乎很难设置，但与使用真实类的可维护性问题相比，结果变得轻而易举。但是有一些框架和技术没有针对接口实现，并且非常难以模拟。如果将这个框架类放在你自己的界面后面太昂贵了，你需要在测试中使用它们。