MockRepository的多个共存实例是否可能？(Are multiple coexistent instances of MockRepository possible? If yes unde

MockRepository的多个共存实例是否可能？(Are multiple coexistent instances of MockRepository possible? If yes under which conditions?)

就编译器而言，Hippomocks的MockRepository支持多个实例。 但是，有些用例是不可能的，因为它们导致单元测试可执行程序崩溃。 让我们考虑以下示例。

void MyCall() { } void MyCall2() { } void MySubTest() { MockRepository mockRep2; mockRep2.ExpectCallFunc(MyCall2); MyCall2(); } void MyTest() { MockRepository mockRep1; mockRep1.ExpectCallFunc(MyCall); MySubTest(); MyCall(); }

此示例（在Visual C ++ 2010中）导致未处理的异常（访问冲突读取位置0x00000048）。

分析Hippomocks标题表明这个用例似乎没有预见到（参见MockRepoInstanceHolder ）。 仅允许一个实例背后的原因是什么？ 我可以理解，例如MockRepository实例中的不同ExpectCallFunc可能会发生矛盾。 这背后的原因是什么？ 我们可以通过将mockRep1实例化移动到MySubTest()调用之MySubTest()解决我们示例中的问题，但我们很难首先理解问题。 是否有编译时或运行时可能明确地识别这样的多个实例？

Hippomocks' MockRepository supports multiple instances as far as the compiler is concerned. Some use cases are not possible, though, as they lead to unit test executable crash. Let's consider the following example.

void MyCall() { } void MyCall2() { } void MySubTest() { MockRepository mockRep2; mockRep2.ExpectCallFunc(MyCall2); MyCall2(); } void MyTest() { MockRepository mockRep1; mockRep1.ExpectCallFunc(MyCall); MySubTest(); MyCall(); }

This example leads (in Visual C++ 2010) to an unhandled exception (access violation reading location 0x00000048).

Analyzing the Hippomocks header shows that this use case doesn't seem to be foreseen (cf. MockRepoInstanceHolder). What is the reason behind allowing only one instance? I can understand that for example different ExpectCallFunc in the MockRepository instances can contradict. Is it the reason behind it? We could solve the problem in our example by moving the mockRep1 instantiation to after the MySubTest() call, but we had a hard time understanding the problem in a first place. Is there a compile-time or run-time possibility to identify such multiple instances explicitly?

最满意答案

根本问题是（编译时生成的）函数没有地方用某个模拟存储库“标记”它，并且与模拟对象不同，它也不能生长为携带它。 这就是持有者的目的 - 从生成的存根函数中找到模拟存储库。

如果有一个很好的用例，通过使该函数中生成的代码更复杂一点，这听起来像一个可解决的问题。 我必须承认，我没有看到直接的直接优势，特别是因为在两个单独的回购中两次模拟相同的功能无论如何都不会起作用（因为你难以覆盖相同的功能）而且会导致很难调试问题，如果你在某些时候混淆它们。 我不认为增加的复杂性和调试困难会与此增加的功能相比。

The root problem is that the (compile-time generated) function does not have a place to 'tag' it with a certain mock repository and unlike mock objects it cannot be grown to carry it as well. That's what the holder is for - to find the mock repository from the generated stub function.

It sounds like a solvable problem if there's a good use case for it, by making the generated code in that function a bit more complex. I must admit that I don't see a direct immediate advantage, especially as mocking the same function twice in two separate repos wouldn't work anyway (because you're hard-overwriting the same function) and it would lead to very difficult to debug problems if you mix them up at some point. I don't think the added complexity and debugging difficulties weigh up against the feature added by this.