模拟整个图书馆 [英] Mocking an entire library

问题描述

我正在开发使用boost::asio的代码.要对其进行测试，我需要从该库中模拟一组类.我正在使用Google Mock，它可以模拟虚拟方法.通常(繁琐)的过程是为我需要使用的每个类编写一个接口.

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.

另一方面，Google Mock Cookbook在模拟非虚拟方法时描述了一种替代方法:使用模板.在我的情况下，问题是我可能需要同时模拟几个类(因此直接使用模板是行不通的).所以我想:为什么不使用两层模板?我想出了以下解决方案:

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;

然后，通常的用法是:

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

测试将是:

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?

推荐答案

这是 python的完美用例齿轮

另请参见此答案.

我已经使用cog为事件列表生成处理程序，该处理程序代码非常通用，我不需要做特殊情况，但是我仍然必须编写所有函数，所以我要做的就是保持.py文件列表中的事件，以及在python函数中生成处理程序样板的代码.因此我能够忠实于 DRY原理

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

很显然，您必须在makefile的预构建中添加cog才能使用工具链

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:

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(' } ')

然后在标题中:

/*[[[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]]]

此外，如果考虑将python添加到您的c ++源代码中的问题是污染"它或美化"它，很大程度上取决于品味和风格.我认为cog对c ++缺乏的模板样式元编程提供了补充，为程序员提供了提供代码整洁度和可读性的工具.但是我不希望每个人都同意

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.

希望这会有所帮助

这篇关于模拟整个图书馆的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！