何时不使用模拟
我有一个基类，它依赖于另一个类来进行一些特殊的缓存。我还写了特殊的缓存类。
我可以测试它，以便将特殊的缓存类作为模拟传递，以确保基类按预期工作，或者我可以使用真实的类来确保整个事情按预期工作。
如果我使用真实的类，我不必在测试缓存类时重复测试逻辑，因为这是它的唯一用例（目前）。
最好的想法可能是编写两个测试（使用模拟和使用真实类），但其他开发人员可能会感到困惑为什么我测试它两次。
我应该在这里使用模拟还是真实的课程？
I have a base class that depends on another class for some special caching. I also wrote the special caching class.
I can test it so special caching class is passed as a mock to make sure the base class works as expected or I can use a real class to make sure that the whole thing works as expected.
If I use the real class I don't have to duplicate test logic in testing the cache class since this is the only use case for it (for now).
The best idea could be to write both tests (using mock and using real class), but it might be confusing to other developers why I test it twice.
Should I use mock here or the real class?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果真正的类能完成工作，你为什么要嘲笑它呢？
我的建议是：
我不会对此感到困惑，只要您的缓存类的测试是详尽的：如果缓存导致问题，缓存测试应该失败，而不是你的外部类。
Why should you mock the real class if it does the job?
My advice would be:
I wouldn't be confused by that, as long as the tests of your cache class are exhaustive: if caching leads to problems, caching tests should fail, and not your outer class.
通常，基类将依赖于另一个类，不一定是为了缓存，而是为了“为我照顾 XYZ”。协作类只是充当存储库。被测试的类不应该知道或关心其他类的缓存 - 否则你可能不需要耦合。
然后，您可以使用接口来表达这一点。我通常称我的为“ILookAfterXYZ” - 我发现这种命名模式确实可以帮助我弄清楚我的协作类可以帮助我做什么 - 并模拟它。
缓存是一个性能问题，而不是行为问题。我提出这个问题是因为它被标记为“BDD”，但我不会在单元或系统级别使用 BDD 风格的测试来确定缓存等内容的有用性。相反，编写性能测试并使用它们来检查缓存是否有效。
Normally, the base class would depend on another class, not necessarily for caching, but for "looking after XYZ for me". The collaborating class is just acting as a repository. The class under test shouldn't know or care that the other class caches - otherwise you have coupling there that you probably don't need.
You'd then use an interface to express that. I normally call mine 'ILookAfterXYZ' - I find this pattern of naming really helps me work out what it is that my collaborating class helps me do - and mock that out.
Caching is a performance concern, rather than a behavioral one. I came to this question because it's tagged "BDD", but I wouldn't use BDD-style tests at either a unit or a system level to determine the usefulness of things like caching. Instead, write performance tests and use them to check that the caching works.
我也遇到过类似的情况，我有一个生产代码类，该类由几个单元测试支持。这些单元测试创建了模拟对象以传递到生产代码类中。这意味着我能够在没有任何依赖项的情况下运行单元测试。
现在，我还需要使用该生产类作为 BDD（使用 SpecFlow）测试的一部分。这种类型的测试更加集成，因为我实际上创建了生产类所需的真实对象（而不是模拟）。
因此，根据我的经验，我仅为单元测试创建了一个模拟对象，同时为我的集成测试创建了一个真实对象。虽然这是非常主观的，但对我来说效果很好。
I've been in similar situations where I had a class in production code which was backed up by a couple of unit tests. These unit tests created mock objects to pass into the production code class. That meant I was able to run the unit tests without any dependencies.
Now, I also required to use that production class as part of a BDD (using SpecFlow) test. This type of testing was more integration, in that I actually created a real object (instead of a mock) which the production class required.
So from my experience I created a mock object only for the unit tests, whilst creating a real object for my integration tests. This is very subjective though, but for me it's worked out fine.