Unit testing of private methods [duplicate]

Answer 1

I know this is an older question, but it seems that nobody has shared the relatively good method that I prefer, so here it goes:

Change the method you wish to test from private to protected. For other classes, the method is still going to be private, but now you can derive a "testing" class from your base class that exposes the private functionality you want tested.

Here's a minimal example:

class BASE_CLASS {
  protected:
    int your_method(int a, int b);
};

class TEST_CLASS : public BASE_CLASS {
  public:
    int your_method(int a, int b) {
      return BASE_CLASS::your_method(a, b);
    }
}

Of course you will have to update your unit tests to run your tests on the derived class instead of the base class, but after that, any change made to the base class will be automatically reflected in the "testing" class.

Answer 2

If the methods are complex enough to warrant testing in isolation, then refactor them into their own class(es) and test via their public interface(s). Then use them privately in the original class.

Answer 3

Make the test class as the friend of the original class. This friend declaration will be inside the #define UNIT_TEST flag.

class To_test_class {
   #ifdef UNIT_TEST
     friend test_class;
   #endif
}

Now for your unit test you will compile the code with flag -DUNIT_TEST. This way you will be able to test the private function.

Now your unit test code will not be pushed into production environment, as UNIT_TEST flag will be false. Hence the code is still secure.

Also you will not need any special library for unit testing.

Answer 4

I don't think unit test cases would be required for private methods.

If a method is private it can used only within that class. If you have tested all the public methods using this private method then there is no need to test this separately since it was used only in those many ways.

Answer 5

The define hack is a horrible idea. Arbitrarily re-writing your code with the preprocessor when you go to compile it is never wise.

Now as several people have mentioned already, it's debatable whether you should be testing private methods at all. But this doesn't cover the case where you've intentionally hidden constructors to restrict instantiaton to certain scopes, or a few other more esoteric cases.

Also, you can't friend a namespace and "friendship" is not inherited in C++ so depending on your unit testing framework you could be in trouble. Luckily, if you're using Boost.Test, there's in elegant solution to this issue in the form of Fixtures.

http://www.boost.org/doc/libs/1_52_0/libs/test/doc/html/utf/user-guide/fixture/per-test-case.html

You can friend the fixture and have it instantiate all of the instances that you use in your unit testing functions, declaring them as static to the fixture and with module scope. If you're using a namespace don't worry, you can just declare your fixture within the namespace and your test cases outside of the namespace, and then use the scope resolution operator to get to the static members.

The BOOST_FIXTURE_TEST_CASE macro will take care of instantiating and tearing down your fixture for you.

Answer 6

After many hours this is what I decided to be the best solution for ones that want to test their private functions. This is combination of answers by Max DeLiso and Miloš.

If you are using boost::unit-test then there's an easy and elegant solution.

1. Use protected instead of private in your classes

   /* MyClass.hpp */
   
   class MyClass {
   
   protected:
       int test() {
           return 1;
       }
   };
   

2. Create a fixture:

   /* TestMyClass.cpp */
   
   class F : public MyClass {};
   
   
   BOOST_FIXTURE_TEST_SUITE(SomeTests, F)
   
   // use any protected methods inside your tests
   BOOST_AUTO_TEST_CASE(init_test)
   {
       BOOST_CHECK_EQUAL( test(), 1 );
   }
   BOOST_AUTO_TEST_SUITE_END()
   

This way you can freely use any of the MyClass functions without #define private public or adding friends to you class!