Good practices for unit-testing class hierarchies

Question

What are common/widely accepted practices for unit testing class hierarchies?

I've tried to look for different questions that are related to this problem, but couldn't find comprehensive one.

Let's suppose there is a hierarchy under test.

class Base 
{
        int base_internal() { return 10;}                

    public:
        int virtual do_f() { return 0; }

        int execute() {
            return do_f()*base_internal();
        }
};

class DerrivedA : public Base
{
        int a_specefic() { return 4; }

    public:
        int virtual do_f()  { return a_specefic(); }
};


class DerrivedB : public Base
{
        int b_specefic() { return 8; }

    public:
        int virtual do_f()  { return b_specefic(); }
};

Now for unit testing infrastructure I am thinking about two strategies here.

Strategy 1. Have "tester" class for each type, derive from appropriate class and do the testing

class TestForBase : public Base {...};
class TestForDerrivedA : public DerrivedA {...};
class TestForDerrivedB : public DerrivedB {....};

Strategy 2. Use "concertized" version of visitor design pattern, (which will have single TestVisitor), than modify each class under test with accept() method, and do the testing inside visit() of Tester class

class Base 
{
        void accept(Tester& t);
        int base_internal();

    public:
        int virtual do_f();
        int execute();
};


class Derrived : public Base
{
        void accept(Tester& t);
        int a_specefic();

    public:
        int virtual do_f();
};

struct Tester
{
        void visit(Base* b)  { ... };
        void visit(Derrived* d) { ... } ;
};

What are the other options?

I fail to understand what problem you're trying to solve. Why would you need dynamic dispatching at all ? Just write code to test the various derived classes. — Quentin, Apr 11 '19 at 15:14
There is no problem, the question is asking about good practices. I don't think having just code testing derived classes would be a good solution. — libxelar.so, Apr 11 '19 at 15:18
Well, you will have to write that testing code, be it in a visitor, a derived class or somewhere else. My question is, why add dynamic dispatching to your tests themselves, or why do you think it would be a good thing to do so? Are you using a specific testing framework that works that way? — Quentin, Apr 11 '19 at 15:29
do not create unit test "one to one" to tested classes. It is bad it couples test with implementation details as a result it will be hard to do refactoring. I recommend to read "Clean Code" Robert C. Martin or search internet for his "Uncle Bob" talks. Good practices of UT is to broad topic for SO. — Marek R, Apr 11 '19 at 16:06
@Quentin Ok, now I got your question. Obviously there is assumption that there "framework" say test runner class. If we do not provide any relation/pattern within our tests, we don't have flexibility in the test runner. Take an example of trivial solution to keep all "separated" test instances as members of runner class. We will forced to modify the runner and add new instance each time there is new class under test. So there should be general approach how to build unit test classes for test hierarchies. Hope this helps. I'll update the question to be more explanatory. — libxelar.so, Apr 11 '19 at 16:10

Good practices for unit-testing class hierarchies

0 Answers0