C++ Unit Testing – What is the Correct Approach to Test Classes with Inheritance?

ctestingunit testing

Assuming I have the following (over-simplified) class structure:

class Base
{
  public:
    Base(int valueForFoo) : foo(valueForFoo) { };
    virtual ~Base() = 0;
    int doThings() { return foo; };
    int doOtherThings() { return 42; };

  protected:
    int foo;
}

class BarDerived : public Base
{
  public:
    BarDerived() : Base(12) { };
    ~BarDerived() { };
    int doBarThings() { return foo + 1; };
}

class BazDerived : public Base
{
  public:
    BazDerived() : Base(25) { };
    ~BazDerived() { };
    int doBazThings() { return 2 * foo; };
}

As you can see, the doThings function in the Base class returns different results in each Derived class due to the different values of foo, while the doOtherThings function behaves identically across all classes.

When I wish to implement unit tests for these classes, the handling of doThings, doBarThings / doBazThings is clear to me – they need to be covered for each derived class. But how should doOtherThings be handled? Is it good practice to essentially duplicate the test case in both derived classes? The issue becomes worse if there are half a dozen functions like doOtherThings, and more Derived classes.

Best Answer

In your tests for BarDerived you want to prove that all (public) methods of BarDerived work correctly (for the situations you have tested). Similarly for BazDerived.

The fact that some of the methods are implemented in a base class does not change this testing goal for BarDerived and BazDerived. That leads to the conclusion that Base::doOtherThings should be tested both in the context of BarDerived and BazDerived and that you get very similar tests for that function.

The advantage of testing doOtherThings for each derived class is that if the requirements for BarDerived change such that BarDerived::doOtherThings must return 24, then the test failure in the BazDerived testcase tells you that you might be breaking the requirements of another class.

Related Solutions

C++ – Initializing Derived Classes Consistently

You want a "mixin". In C++ they are usually implemented with templates and specifically using CRTP, the "curiously recurring template pattern". It might be an overkill if it's just a bit of common code, than Pierre's answer seems most appropriate. But as the amount of common code for the mock classes grows, so will value of template.

Basic CRTP would go like this:

template <typename ConcreteT> class Mock {
    initMock() {
        static_cast<ConcreteT *>(this)->x = 1;
        static_cast<ConcreteT *>(this)->y = "abc";
        static_cast<ConcreteT *>(this)->z = 0.5;
    }
};

class MockA : A, Mock<MockA> { ... };
//                    ^^^^^ specialized on the type that inherits it, that's the point

Here it would make things simple to inherit A through the Mock class though, so

template <typename BaseT> class Mock : public BaseT {
    initMock() {
        x = 1;
        y = "abc";
        z = 0.5;
    }
};

class MockA : Mock<A> { ... };
//                 ^ just the base class

That does away with the ugly static_casts, but does not allow you to provide methods in MockA that will be called by Mock. But you can have both...

template<typename ConcreteT, typename BaseT>
class Mock : public BaseT { ... };

class MockA : Mock<MockA, A> { ... };

Now Mock can call methods of MockA on itself via static cast and call methods of A (or rather the ultimate base) directly.

Note: The mixin templates are basically the same thing as mixins in Ruby or interfaces with method implementations introduced in Java 8. Those languages it is a special construct, because they don't have anything of the power of C++ templates, but the implementation is similar—an intermediate class is constructed by compiler and injected in the hierarchy.

Using Protected Inheritance to Hide Implemented Interface in C++

We can establish that it is legal (i.e. valid) C++ because it compiles. You've used it on GCC and clang and I've done exactly same thing with MSVC++ so that covers the majority of the compiler market.
This is why protected/private (btw, I would use private) modifier was introduced. It allows your class to implement callback interfaces which are needed for other classes it is using internally, but a) the rest of the world doesn't need to know that you are using those other classes and b) the rest of the world should not be able to even call on any of those functions because they are meant to be hidden and used only by internals.

When I transitioned from C++ to C#, I actually felt weird that I couldn't have private interface inheritance. If something is an implementation detail and not intended to be seen/used by the public, it should be kept hidden and I think the method you described is a great and simple way of doing that.
Using pImpl just generates more overhead. When you allocate your objects (obviously assuming dynamic allocation), you end up going to the heap twice as many times. You also reduce the locality of your code because now View and ViewImpl might be in different pages in memory and will cause more cache misses. And you've increased the amount of boiler plate code you have to write because now you are forwarding all public interface calls from the View to ViewImpl.

This is all just my opinion but in the end, I cannot think of any reason not to have private interface inheritance. I've written code like this for 6+ years and never had any readability/maintainability problems because of it.

Best Answer

Related Solutions

C++ – Initializing Derived Classes Consistently

Using Protected Inheritance to Hide Implemented Interface in C++

Related Topic