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

发布于 2024-07-19 21:25:17 字数 80 浏览 5 评论 0原文

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

I have read many articles about unit testing.
Most of the articles said that we should not use more than one mock object in a test, but i can't understand why.
Sometimes we really need more than one mock object in a test.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

能否归途做我良人 2024-07-26 21:25:18

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

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

  • 防止过度嘲笑。 当单元测试模拟出所有协作者时,你就敞开大门; 当您替换真正的协作者时,该场景可能会失败。 通过最大限度地减少模拟数量并尽可能使用真正的合作者,您可以最大限度地降低风险。
  • 高耦合警报:如果您发现自己必须模拟大量协作者才能编写单元测试,则可能是一种设计味道,表明您具有高耦合性。

You can have more than one mock in a unit test depending on the context.

However I think what 'the articles' might be hinting at is

  • prevention of over-mocking. When a unit-test mocks out all collaborators, you leave the door open; the scenario might fail when you substitute real collaborators. By minimizing the number of mocks and using real collaborators as far as feasible/possible, you minimize that risk.
  • High Coupling alerts: If you find yourself having to mock lots of collaborators inorder to write a unit test, it might be a design smell indicating that you have high coupling.
白日梦 2024-07-26 21:25:18

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

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

我知道这种“最佳实践”只有一个模拟,但也不理解它。 在我们的单元测试中,我们有很多模拟,一些环境模拟是由我编写的测试框架设置的(例如TransactionService,SecurityService,SessionService)。 只有一件事需要考虑,正如 Gishu 在他的回答中已经提到的那样,许多模拟表明高度依赖。 太多的时候就由你自己考虑了。 我们有很多小接口,在测试中需要很多mock。

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

  • 它是被测类的高度耦合部分,如内部类、私有类等。
  • 它是常见的 .NET 框架类像集合之类的
  • 您想要编写一个集成测试来准确测试与该类的交互。 (您仍然模拟其他所有内容,并且仍然对每个涉及的类进行单独的单元测试。)
  • 模拟某个类的成本太高了。 谨慎决定它太昂贵,模拟似乎很难设置,但与使用真实类时遇到的可维护性问题相比,这是一件轻而易举的事。 但有些框架和技术并不是针对接口实现的,并且很难模拟。 如果将此框架类放在您自己的接口后面成本太高,则您需要在测试中接受它们。

You should add as many mocks as necessary to isolate your class under test. You need a mock for every dependency that should not be part of the test.

Sometimes you put two or three classes together in a test, for simplicity, because they build something like a component and are highly coupled. Everything else should be mocked.

I know this "best practice" to have only one mock and also do not understand it. In our unit tests, we have many mocks, some environmental mocks are set up by the test framework I wrote (eg. TransactionService, SecurityService, SessionService). There is only one thing to consider, as Gishu already mentioned in his answer, many mocks are an indication of high dependency. It's up to you to consider when it is too much. We have many small interfaces, which requires many mocks in tests.

To turn your answer around, you should not mock a dependency when:

  • It is a highly coupled part of the class under test, like an inner class, private class etc.
  • It is a common .NET framework class like a Collection and the like
  • You want to write an integration test to test exactly the interaction with that class. (You still mock everything else and you still have unit tests for every involved class in isolation.)
  • It is just to expensive to mock a certain class. Be careful with deciding it as too expensive, mocks seem to be hard to set up, but turn out to be a breeze compared to the maintainability problems you'll have with using real classes. But there are some frameworks and technologies that are not implementing against interfaces and are very hard to mock. If it is too expensive to put this framework classes behind your own interface, you need to live with them in the tests.
|煩躁 2024-07-26 21:25:18

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

I'm not sure what articles you're referring to, but I typically have one mock object per dependency for the class under test.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文