Mocking an entire library

问题

I'm developing code that uses boost::asio. To test it, I need to mock a set of classes from this library. I'm using Google Mock, which allows for mocking virtual methods. The usual (and tedious) process would be to write an interface for each of the classes I need to use.

On the other hand, the Google Mock Cookbook describes an alternative when it comes to mocking non-virtual methods: using templates. The problem in my case is that I might need to mock several classes at the same time (so using templates directly wouldn't work). So I thought: why not use two-levels of templates? I came up with the following solution:

// Classes to be mocked.

class RealA
{
public:
    void a() { cout << "RealA::a()" << endl; };
};

class RealB
{
public:
    void b() { cout << "RealB::b()" << endl; };
};

// Mock classes.

class MockA
{
public:
    void a() { cout << "MockA::a()" << endl; };
};

class MockB
{
public:
    void b() { cout << "MockB::b()" << endl; };
};

template<class ABFactory>
class Program
{
public:
    void setFactory(ABFactory* factory) { factory = factory; }
    void useA() { typename ABFactory::A* a = factory->createA(); a->a(); delete a; }
    void useB() { typename ABFactory::B b; b.b(); }

private:
    ABFactory* factory;
};


template<class ParamA, class ParamB>
class TABFactory
{
public:
    typedef ParamA A;
    typedef ParamB B;
    A* createA() { return new A; };
    B* createB() { return new B; };
};

typedef TABFactory<RealA, RealB> RealABFactory;
typedef TABFactory<MockA, MockB> MockABFactory;

Then, the normal usage would be:

Program<RealABFactory> p;
p.useA();
p.useB();

While the test would be:

Program<MockABFactory> t;
t.useA();
t.useB();

This starts to get complicated when the mocked classes have methods with complex parameters (such as other classes from the same library which might not be mocked). In summary, it doesn't seem to scale. Any thoughts on this solution, or suggestions on other approaches to the problem?

回答1:

this is a perfect use case for python cog

see also this answer.

I've used cog to generate handlers for a list of events, the handler code is very generic and i don't need to do special cases but i still have to write all the functions, so what i did is keep the events in a list in a .py file and the code to generate the boilerplate of the handlers in a python function. so i'm able to be faithful to the DRY principle

obviously you'll had to add cog to the pre-build of your makefile in order to work with your toolchain

Edit as an example of the code generation design required for adding boilerplate to your classes, i would do something like:

myCodeGeneration.py

import cog
ClassesToMock = [ [ 'IfaceA' , 'classA' , 'mockA' , ['void doSomething(int foo)' , 'int getSomething()'] 
                 , [ 'IfaceB', 'classB' , 'mockB' , ['static classA& getInstance()'] ]

def addInterfaces( myStructure ):
   for classItem in myStructure:
      cog.outl('class %s { ' % classItem[0] )
      for methodDecl in classItem[3]:
         cog.outl(' virtual %s = 0;' %methodDecl )
      cog.outl(' } ')

#implement your real classes normally

def addMocks( myStructure ):
   for classItem in myStructure:
      cog.outl('class %s : public %s { ' % classItem[2] % classItem[0] )
      for methodDecl in classItem[3]:
         cog.outl(' %s {' %methodDecl )
         cog.outl(' MOCK_STUFF_MACRO ')
         cog.outl(' } ')
      cog.outl(' } ')

then in your header:

IfaceA.h

/*[[[cog
import cog
import myCodeGeneration

myCodeGeneration.addInterfaces( [ [ 'IfaceA' , 'classA' , 'mockA' , ['void doSomething(int foo)' , 'int getSomething()'] ] )
]]]*/

//your code will be generated here

//[[[end]]]

mockA.h

/*[[[cog
import cog
import myCodeGeneration

myCodeGeneration.addMocks( [ [ 'IfaceA' , 'classA' , 'mockA' , ['void doSomething(int foo)' , 'int getSomething()'] ] )
]]]*/

//your code will be generated here

//[[[end]]]

Also, the issue if considering adding python to your c++ source is 'polluting' it or 'beautifying' it is largely a matter of taste and style. I consider that cog provides a complement to template style metaprogramming that is lacking in c++, giving the tools to the programmer to provide code tidiness and readability. But i don't expect everyone to agree

For me the whole architectural design principle behind this approach is Don't Repeat Yourself. errors happen when we have to encode a method in several places manually. Let the computer automate what its automatable and encode things that cannot just once. As a side-effect, it will make your coding more enjoyable, both for writing it and reading it later.

hope this helps

来源：https://stackoverflow.com/questions/10260464/mocking-an-entire-library