1

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

4

3 回答 3

5

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

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

  • 防止过度嘲笑。当一个单元测试模拟出所有的合作者时，你把门开着；当您替换真正的合作者时，该场景可能会失败。通过尽量减少模拟的数量并尽可能地使用真正的合作者，您可以最大限度地减少这种风险。
  • 高耦合警报：如果您发现自己必须模拟许多协作者才能编写单元测试，这可能是一种设计气味，表明您具有高耦合。
于 2009-05-12T07:05:05.983 回答
3

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

于 2009-05-12T06:53:05.770 回答
3

您应该根据需要添加尽可能多的模拟来隔离您的测试类。您需要为每个不应该成为测试一部分的依赖项进行模拟。

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

我知道这个“最佳实践”只有一个模拟并且也不理解它。在我们的单元测试中，我们有很多模拟，一些环境模拟是由我编写的测试框架设置的（例如 TransactionService、SecurityService、SessionService）。只有一件事需要考虑，正如 Gishu 在他的回答中已经提到的那样，许多模拟表明高度依赖。当它太多时，由你来考虑。我们有很多小接口，这需要在测试中进行很多模拟。

为了扭转你的答案，你不应该在以下情况下模拟依赖：

  • 它是被测类的高度耦合部分，如内部类、私有类等。
  • 它是一个常见的 .NET 框架类，如 Collection 等
  • 您想编写一个集成测试来准确测试与该类的交互。（您仍然模拟其他所有内容，并且您仍然对每个涉及的类进行单独的单元测试。）
  • 模拟某个课程太昂贵了。小心决定它太昂贵，模拟似乎很难设置，但与使用真实类的可维护性问题相比，它变得轻而易举。但是有些框架和技术没有针对接口实现，并且很难模拟。如果将此框架类放在您自己的接口后面太昂贵，您需要在测试中使用它们。
于 2009-05-12T20:14:01.547 回答