How to use mock objects [C++] without passing them as arguments to functions

Question

I'm in the process of integrating a Unit Testing Framework for an existing code base in C++. I've zeroed down on CxxTest, but as it turns out we can use other Mocking Frameworks (like googlemock) in conjunction with CxxTest too.

After reading tutorials on CxxTest (Mocking) and googlemock (the infamous turtle example), I have the general idea that you have to define a mock class (using macros etc), declare an object of the mock class and then pass it to the function you are unit testing. Now, there are many occurences in the existing code base where it isn't possible to do that.

Here's an pseudo example to clarify:

class CCandidateForTest
{
    public:
    bool foo(int a)
    {
        CAnotherClass obj;
        int b = obj.bar(a+2);
        if (a == b) {
            return true;
        } else {
            return false;
        }
    }
}

(This is over-simplified, there are also exceptions and the primitive types may also be other objects etc.; but you get the general idea) (also, creation of objects is not always direct and may sometimes use a factory)

I want to write a test for the function CCandidateForTest::foo. This method internally creates an object of CAnotherClass, which I need to mock so that CAnotherClass::bar returns different values so that different code paths in foo are traversed in unit testing.

In a nutshell, the problem is that the function being tested internally creates an object of the class that needs to be mocked - hence passing an instance of the mocked object to the function is not possible.

How do I use mocking in such a case? Is there a specific mocking framework that makes this possible?

Answer 1

You could use a factory to create instances of CAnotherClass.

class CCandidateForTest
{
    public:
    bool foo(int a)
    {
        std::shared_ptr< CAnotherClassInterface > obj = CAnotherClassFactory::Create();
        int b = obj->bar(a+2);
        if (a == b) {
            return true;
        } else {
            return false;
        }
    }
}

CAnotherClassFactory can look like :

class CAnotherClassFactory
{
public:
    typedef std::shared_ptr< CAnotherClassInterface > (*fn)();
    static std::shared_ptr< CAnotherClassInterface > Create()
    {
        return createFn();
    }

    static fn createFn;
};

---

Random thoughts about your approach :

• If that is over-simplified, then you need to think how to refactor it.
• there are better unit test frameworks then cxxunit. gtest and cute-test.com

Answer 2

If a class internally creates objects to do its job, then that object isn't a "collaborator" at all. For testing purposes, this is exactly the same situation as if it had a lot of inline code doing the same thing. In other words, you can't mock this object because from the perspective that the test has to assume, it doesn't exist!

(This may be an indicator of your class doing too much, and it can be an argument when weighing whether to refactor the class so that it does have a true collaborator, but it is only one factor - there may be other good reasons to leave the class unchanged and test its behaviour as well as possible without mocking.)

Answer 3

Use a factory. Have the candidate class take in the factory in the constructor. Mock the factory for your test. You can use a mock lib for that or simply use separate prod and test impls of an pure abstract factory class.

Answer 4

I saw that we had function which internal generated/created its own object for manipulating. From my view, it's not truly testable code. Therefore, if we tried to make unit test for it, it may not reflect true value of TDD here. In addition, it can make your unit test code and mock objects more complex. In balance way, we should have some refactor code before doing any UT then. We can do some way to refactor implementation such as: pass more argument to make it more compliant with testable code, use factory pattern/global function to generate object..