1

I am investigating using mocking for unit tests I'm adding to existing code. For this I'm using HippoMocks. This involves another class calling some methods on my mock (that are all virtual). I want to avoid overspecifying all this but HippoMocks keep throwing NotImplementedException whenever the other class calls functions on my mock that I have not specified.

The below code exposes my issue.

void test()
{
    class SimpleClassToMock
    {
    public:
        virtual void memberFunction1() {}
        virtual void memberFunction2() {}
    };

    MockRepository mocks;
    // true or false here makes no difference.
    mocks.autoExpect = true;

    SimpleClassToMock* m = mocks.Mock<SimpleClassToMock>();
    // I care about this function getting called.
    mocks.ExpectCall(m, SimpleClassToMock::memberFunction1);

    m->memberFunction1();
    // HippoMocks fails on the next line by throwing NotImplementedException.
    m->memberFunction2();
}

Is there any way to tell HippoMocks not to fail here? I only want to specify the expectations for things I care about for a particular test, not every single thing that is called.

PS: To those that have mocking experience, am I thinking about this all wrong? Is overspecifying the test in cases such as this not a problem/"what you want"?

Sebastian Ärleryd
  • 1,774
  • 14
  • 19

1 Answers1

1

To avoid overspecifying, you can use OnCall to allow them to be called 0-N times (optionally with argument checks, order checks and so on).

dascandy
  • 7,184
  • 1
  • 29
  • 50
  • Thanks for answering. If there's no way of not having to specify everything that is called then I guess this is the answer. Is that correct? Would it be impossible in C++ to add support in HippoMocks for not throwing a `NotImplementedException` in the above case? Commenting out the throw makes the test work at least (I'm fully aware that this might very well be completely undefined behavior). I could maybe patch HippoMocks with this functionality. – Sebastian Ärleryd Jan 27 '17 at 11:20
  • The difficulty is that the return type is impossible to know without such a call. On Linux or similar systems this results in it being undefined and unconstructed, so any object return value would be undefined behaviour, but on Windows it's not even possible to return at all as the callee has to destruct the stack contents. The only valid return, without knowing the function signature, is to throw an exception. The only way to know the signature is to ask the user, at least until C++ gets actual compile-time reflection. – dascandy Jan 27 '17 at 15:04
  • Ah, that makes very much sense! I suspected you had a very good reason behind the current limitations, sorry for not making that clear in my question. Then what HippoMocks does is the best possible solution then! This is then the best possible answer I could get to my question. Thanks so much for clarifying all this! – Sebastian Ärleryd Jan 29 '17 at 01:25
  • 1
    You're welcome. I'm looking together with others in C++ SG7 to see how to make this limitation go away entirely. It will take many years though, sadly - at least 2023 and probably later. See for details https://github.com/dascandy/reasoning-about-names – dascandy Jan 29 '17 at 10:11