How to access private class fields from a test using UnitTest++?

Question

I'm facing a nuisance when coding my unit tests using UnitTest++. I'm wondering how to access private member class fields in a clean way (or maybe any way...)

By now, I have a solution to access protected members using a class fixture deriving from the class under test. The following code shows the idea:

struct MyFixture : ClassUnderTest { };

TEST_FIXTURE(MyFixture, OneTest)
{
    do_something();
    CHECK(protected_field == true);
}

Nevertheless, I think this is not very clean, because problems relating inheritance could arise in some configurations and, anyway, just protected members can be accessed and tested.

I tried to declare test classes as friends, but as these are created in some special way by UnitTest++, I haven't managed to do it yet.

Does anyone have any idea of how to make test classes friends of the the classes under test?

Is there another way of approaching this problem in an easier or different way?

Thank you all in advance.

Answer 1

Unit testing is all about testing your objects through their public interface. The fact that it might be hard is why writing testable code is sometimes referred to as art. Not everyone can write testable code right away, that's why people invented XP approach of writing tests first. Sounds unrealistic, works in reality.

However, if you absolutely need to test private functions, here is a list of methods I would consider in order of my own preference:

1. Private member variables are to be accessed via public setters and getters.

2. I would recommend making you private member function a non-static non-member function in a namespace that can be called e.g. details or internal. Don't declare it in the header file, just define it in the same file where your class functions are defined. Add its declaration in a myClass_internal.h header file in the unit test project and test it. Difficulties involved depend largely on the complexity of your architecture.

3. Make your test class inherit from your testable class. This doesn't involve changing your code much, but might require use of multiple inheritance, which in some places is even banned.

4. Make your test a friend of your testable class. Difficulty depends on the test framework you are using. Say, with gtest that I use, it's pretty hard :)

5. A hack with redefining public and private should be your absolutely last resort if everything else fails. Although I would rather think of changing the design to a more testable one instead.