[feature request] Add support to mock nonvirtual member functions.

[ghost]

I have wrote test example to mock member function to prove It's possible. Can You add more comfortable way to do such mocks? Member functions do not differ very much from free functions, so why not to intercept it the same way? They have __thiscall calling conversion, which can be intercepted exactly by the same "jmp" instruction as common function.

#include "hippomocks.h"

#include <iostream>

class Test
{
public:
  int mem_fun()
  {  return 100; }
};

int main()
{
  MockRepository mocks;

  Test t;
  int(Test::* mem_ptr)() = &Test::mem_fun; // get member function address
  void* mem_fun_ptr = (void*&)mem_ptr;    // convert it to common address
  int (*mem_st)(Test*) = reinterpret_cast<int(*)(Test*)>(mem_fun_ptr);  // convert it to required address type
  mocks.OnCallFuncOverload(mem_st).Return(111);

  std::cout << "Test::mem_fun() " << t.mem_fun() << std::endl;
  return 0;
}

[aswna]

+1 Would be very useful!

[dascandy]

It's been done once before and I think I can dig up the changelist but it has very big problems and implications, which is why it's not there now:

• Non-virtual member functions are inlined often. Inlined functions cannot be mocked.
• The way of mocking it modifies global state (the function itself). While this was considered OK for global functions (you only do that in cases you don't actually want to call the underlying function) for member functions this does not apply, and it is very odd to have a misbehaving object if you mock another instance of it. It does not match virtual member mocking at all.
• Because of modifying global state you are inherently thread-unsafe. HippoMocks is basically thread safe (or possible to be made thread safe) unless you use function mocks - and in that case it's still OK, unless it needs to actively go back and forth between having the function mocked and not mocked.
• It's a major performance bottleneck; it loads code into the data cache and modifies it. On P4's this used to result in slowdowns of over 99% for code heavily impacted by it, and use as member functions would strongly imply moving back and forth (depending on instance) between having it mocked & not mocked, causing this slowdown to happen a lot.

In short, I see that it could be useful, it would be dangerous to use even on unoptimized debug builds as the compiler may have inlined or omitted something, it would cause major performance issues if you actually were to use it and its interface is confusing. So as far as I'm concerned it's a no.

[aswna]

Thanks for the detailed explanation.

[Europar]

I'm starting to use HippoMocks to help unit testing our product. It would be great if we can have this feature optional. I totally understand the few problems you listed out, however I find our unit test environment has none or less of the problems:

• We do use Macro to tell compiler not to inline certain functions for non-release build, for testing
• For each test case we don't mix the original function with the mocked version, it's perfectly OK to modify the global state, in fact we are using link time substitution to use the mocked version at link time
• We don't do threading in unit test
• As we are using HippoMocks in an unit test environment, there's really no performance issue

[dascandy]

Will update documentation with rationale why this is not going to be added. It's an often requested feature but it's too likely to cause trouble for most users.

If you disagree, feel free to fork the project though.