Exception messages can be much more helpful

[provegard]

The message given by CallMissingException lacks call details. I modified the CallMissingException constructor to mimic that of NoResultSetUpException:

        CallMissingException(MockRepository *repo, const base_tuple *tuple, const char *funcName)
        {
            std::stringstream text;
            text << "Function with expectation not called: ";
            text << funcName;
            if (tuple)
                tuple->printTo(text);
            else
                text << "(...)";
            text << std::endl;
            text << *repo;
            txt = text.str();
        }

Any reason not to use this?

[provegard]

Hm, is the idea to manually deduce this from the repo output, under "Expectations set"?

[dascandy]

That's actually I think one of the longest-lasting TODOs in the code - making the exceptions more useful & less verbose. This is the most hurtful one - can you send a pull request for that fix?

[provegard]

Sure! However, in my particular case I realized just after posting the issue that I could just look in the "Expectations set" list to find out which the call was. So now I think that perhaps the issue is not that relevant. :-) But what is your idea of more useful and less verbose?

[dascandy]

When printing the list of functions it gives you no indication about what function was called, what arguments would be present if that function was the one called (ie, interpreting the stack), it lists all functions when it could reduce the set to ones with the same amount of arguments, with similar signatures, similar names or so in most cases. One in particular is to at least highlight the other expectations on the same object, so you can tell what has and hasn't happened on that object.

[provegard]

So, an object (mock) centric view? In case of a failure, here's what I would like to know:

• For a missing call, what the expected call was and where I defined it. Prior interactions with the mock is a bonus (and I take it this is what you meant with your last sentence?).
• For a mismatching call, a diff of the argument lists.
• A call stack.

I'm not particularly interested in optional setups used and interaction with other mocks, because that sort of follows from how far we got in the test case. It sure adds a lot of noise.

Getting a call stack in Windows seems to be doable but the code won't be as short as the one for Linux.

I'm all for contributing with a PR, but I'd like to know if you have some specific requirements/demands/wishes.

[dascandy]

Sorry for taking so long to get back to you. I've refactored the reporting code to be separate from HippoMocks itself, and to include the call itself. On Linux a call stack is now present in some cases.

I've forwarded the call context to the reporter, but haven't implemented the detailed logging yet.

If you still want to make a PR out of it, please feel free - I completely agree with the approach you outlined. Heck, just getting the calls to this mock highlighted would be much better.