7

I've been trying out using GoogleTest for my C++ hobby project, and I need to test the internals of a component (hence white box testing). At my previous work we just made the test classes friends of the class being tested. But with Google Test that doesn't work as each test is given its own unique class, derived from the fixture class if specified, and friend-ness doesn't transfer to derived classes.

Initially I created a test proxy class that is friends with the tested class. It contains a pointer to an instance of the tested class and provides methods for the required, but hidden, members. This worked for a simple class, but now I'm up to testing a tree class with an internal private node class, of which I need to access and mess with.

I'm just wondering if anyone using the GoogleTest library has done any white box testing and if they have any hints or helpful constructs that would make this easier.

Ok, I've found the FRIEND_TEST macro defined in the documentation, as well as some hints on how to test private code in the advanced guide. But apart from having a huge amount of friend declerations (i.e. one FRIEND_TEST for each test), is there an easier idion to use, or should I abandon using GoogleTest and move to a different test framework?

Improve this question
1
  • 2
    If you persist in doing the wrong thing, then you may as well write a macros that changes instances of private into public when your header files are loaded by the unit test and be done with it.
    – Sardathrion - against SE abuse
    Nov 29, 2011 at 10:17

1 Answer 1

Reset to default
1

You should not really be testing private methods here and here. It makes your tests brittle since a refactor of the internal class code will mean a refactor of some the tests -- thus you lose the confidence that those tests work.

Have you looked at mocks? I think that this approach may help you more.

In addition, have a look here for a similar question.

Improve this answer
6
  • Ok, so how do you verify that code you've written inside of a private section does what it's intended to do? I am not talking about all the tests using these private functions, just the one's that are testing them.
    – Dominik Grabiec
    Oct 2, 2011 at 2:26
  • The reason why you should not test directly the internal of the class is that it makes your tests brittle. If you decide to refactor the code, you will need to re-write some tests and there will be no confidence that the new tests keep the old functionality. You should test the correctness of the private methods by testing the API of the class (aka its public methods). See all the links in my answer for more in depth explanations.
    – Sardathrion - against SE abuse
    Oct 3, 2011 at 7:10
  • 1
    What's wrong with changing the tests when the thing they are testing changes? There should be tests to verify the public class interface, and those should not need to be changed if internals change. If you're using a tree internally (private) and want to test that your tree code is correct, why shouldn't you test that? If you change teh tree to a hash map then you can get rid of those tests (if a built in class), or change them to verify your hash map works as required.
    – Dominik Grabiec
    Oct 3, 2011 at 8:42
  • 1
    Why is your tree not a class in and off itself which you can test via its public methods?
    – Sardathrion - against SE abuse
    Oct 3, 2011 at 8:56
  • It is a class. It is declared private because it's an implementation detail. It is not generic. But some invariants and methods still need to be tested.
    – Dominik Grabiec
    Oct 3, 2011 at 12:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.