What is wrong with making a unit test a friend of

Question

This question already has an answer here:

• How do I test a private function or a class that has private methods, fields or inner classes? 46 answers

In C++, I have often made a unit test class a friend of the class I am testing. I do this because I sometimes feel the need to write a unit test for a private method, or maybe I want access to some private member so I can more easily setup the state of the object so I can test it. To me this helps preserve encapsulation and abstraction because I am not modifying the public or protected interface of the class.

If I buy a third party library, I wouldn't want its public interface to be polluted with a bunch of public methods I don't need to know about simply because the vendor wanted to unit test!

Nor do I want have to worry about a bunch of protected members that I don't need to know about if I am inheriting from a class.

That is why I say it preserves abstraction and encapsulation.

At my new job they frown against using friend classes even for unit tests. They say because the class should not "know" anything about the tests and that you do not want tight coupling of the class and its test.

Can someone please explain these reasons to me more so that I may understand better? I just do not see why using a friend for unit tests is bad.

Answer 1

You should consider that there are different styles and methods to test: Black box testing only tests the public interface (treating the class as a black box). If you have an abstract base class you can even use the same tests against all your implementations.

If you use White box testing, you might even look at the details of the implementation. Not only about which private methods a class has, but what kind of conditional statements are included (i.e. if you want to increase your condition coverage because you know that the conditions were hard to code). In white box testing, you definitely have "high coupling" between classes/implementation and the tests which is necessary because you want to test the implementation and not the interface.

As bcat pointed out, it's often helpful to use composition and more but smaller classes instead of many private methods. This simplifies white box testing because you can more easily specify the test cases to get a good test coverage.

Answer 2

I don't see anything wrong with using a friend unit testing class in many cases. Yes, decomposing a large class into smaller ones is sometimes a better way to go. I think people are a bit too hasty to dismiss using the friend keyword for something like this - it might not be ideal object oriented design, but I can sacrifice a little idealism for better test coverage if that's what I really need.

Answer 3

Make the functions you want to test protected. Now in your unit test file, create a derived class. Create public wrapper functions that call your the class-under-test protected functions.

Answer 4

Like bcat suggested, as much as possible, you need to find bugs using public interface itself. But if you want to do things like printing private variables and comparing with expected result etc(Helpful for developers to debug the issues easily), then you can make UnitTest class as friend to class to be tested. But you may need to add it under a macro like below.

class Myclass
{
#if defined(UNIT_TEST)
    friend class UnitTest;
#endif
};

Enable flag UNIT_TEST only when Unit testing is required. For other releases, you need to disable this flag.

Answer 5

I feel that Bcat gave a very good answer, but I would like to expound on the exceptional case that he alludes to

In the real world, things may not always be so clear, and having a unit testing class be a friend of the class it tests might be acceptable, or even desirable.

I work in a company with a large legacy codebase, which has two problems both of which contribute to making a friend unit-test desirable.

• We suffer from obscenely large functions and classes which require refactoring, but in order to refactor it is helpful to have tests.
• Much of our code is dependent on database access, which for various reasons should not be brought into the unit tests.

In some cases Mocking is useful to alleviate the latter problem, but very often this just leads to uneccessarily complex design (class heirarchies where none would otherwise be needed), while one could very simply refactor the code in the following way:

class Foo{
public:
     some_db_accessing_method(){
         // some line(s) of code with db dependance.

         // a bunch of code which is the real meat of the function

         // maybe a little more db access.
     }
}

Now we have the situation where the meat of the function needs refactoring, so we'd like a unit test. It shouldn't be exposed publicly. Now, there's a wonderful techniche called mocking that could be used in this situation, but the fact is that in this case a mock is overkill. It would require me to increase teh complexity of the design with an unecessary heirarchy.

A far more pragmatic approach would be to do something like this:

 class Foo{
 public: 
     some_db_accessing_method(){
         // db code as before
         unit_testable_meat(data_we_got_from_db);
         // maybe more db code.    
 }
 private:
     unit_testable_meat(...);
 }

The latter gives me all of the benefits I need from unit testing, including giving me that precious safety net to catch errors produced when I refactor the code in the meat. In order to unit test it, I have to friend a UnitTest class, but I would strongly argue that this is is far better than an otherwise useless code heirarchy just to allow me to use a Mock.

I think this should become an idiom, and I think it's a suitable, pragmatic solution to increase the ROI of unit testing.

Answer 6

Ideally, you shouldn't need to unit test private methods at all. All a consumer of your class should care about is the public interface, so that's what you should test. If a private method has a bug, it should be caught by a unit test that invokes some public method on the class which eventually ends up calling the buggy private method. If a bug manages to slip by, this indicates that your test cases don't fully reflect the contract you wish your class to implement. The solution to this problem is almost certainly to test public methods with more scrutiny, not to have your test cases dig into the class's implementation details.

Again, this is the ideal case. In the real world, things may not always be so clear, and having a unit testing class be a friend of the class it tests might be acceptable, or even desirable. Still, it's probably not something you want to do all the time. If it seems to come up often enough, that might a sign that your classes are too large and/or performing too many tasks. If so, further subdividing them by refactoring complex sets of private methods into separate classes should help remove the need for unit tests to know about implementation details.