Unit testing - setting private members to get desired object state

Question

I'm taking my first steps with unit testing and have a problem with encapsulation. My class has some private member variables that shouldn't be visible to the client, but in order for me to put object in a state I want to test it under, I need to set those private variables.

Say I have a code like that:

Class Foo {

public:
  int action() ;  
private:
  int state ;

} ;

int Foo::action()
{
  if(this->state == 1)
    return 1 ;
  else
    return 0 ;
}

So now I want to test Foo::action(), but I need to be able to set Foo::state to be able to check function under different scenarios. One solution is the evil "define private public" in tests code. But is there something more elegant? I would like to stress that Foo::state is a variable that shouldn't be accessed by client, so I don't want to declare any public setter.

Edit:

I now think that extending the class I want to test in test code and including setters in that derived class would work, providing I changed private variables to protected. But that's a 'one generation only' solution and still feels like a hack rather than a proper approach.

Edit 2:

After reading answers and comments I was given (thanks to Lieven and ap. in particular) I believe the actual class I'm trying to test now (not the simple example I provided) simply does too much and the answer to my problem is moving some of its logic into another class that will be used by the big guy.

Answer 1

There are only two posibilities (refactoring asside)

1. Use the public interface to set the state.
2. The state is redundant if you can't set it to through the public interface.

Option 2 is self explanatory and most likely not applicable to your case so you are left with setting the state through the public interface of your class.

As you have already mentioned, this is possible but it requires a lot of code to get to the right state. That in itself could be an indication that your class is currently doing to much and it's time to refactor parts of your class into smaller, testable classes.

From Do not test private methods

If you find the need to test a private method, then you’re doing something else wrong. There is an “upstream” problem, so to speak. You have arrived at this problem due to some other mistake previous in this process. Try to isolate what that is, exactly, and remove that rather than bending your tests to go down a painful road of brittleness in testing.

and Unit testing private members

I'd recommend not unit testing private methods. Since they're private, they may be changed in any conceivable (or inconceivable?) manner between each release. If a given private method is so critical to the operation of the class that you feel it deserves test cases, then it's probably time to refactor that out into a protected or public method

A common quote on this is

You should never touch your privates

Answer 2

If your test class is called MyTestClass, then add MyTestClass as friend in class Foo to be able to access its private member variables.

Class Foo {
public:
    int action();  
private:
    int state;

    friend class MyTestClass;
};

Answer 3

You should be having some publicly (or "protectedly") accessible mechanism to change the value of the private variable state. For simplicity, let's say it is a method Foo::setState(int inState). Use that in the unit test to change the state, and thus test the Foo::action() method. This ensures that any future implementation changes would not affect the unit test (unless the "API" Foo::setState() changes - in which case, of course, you have to change the unit test).

If you do not have such a mechanism to change state, it means the end user or calling code cannot change it either, and hence, you wouldn't need to test it (and maybe that makes state redundant, but I don't know about that).

If the private variable changes "indirectly" through other code, you will have to execute the same code in the unit test. You can always trace back any method visible externally to inputs fed to the code externally. Basically the point is that in the unit test, you would have to feed the same inputs to the code as in the "real" scenario, and then test if it responds as it should.

As discussed in the comments below, if the "path" from the input to the code being tested is too long, the code/test may have to be broken into smaller modules or intermediate points. To elaborate, consider the code flow as:

Input -> A -> B -> C -> Output
// A, B, C are intermediate execution points which are not "publicly accessible".

In the above case, all you can do is

Given Input, check if Output is correct.

Instead, it would be good to expose the intermediate A, B, C, at least to the unit tests, so that you can now break your test into:

Given Input, check if A is correct.

Given A, check if B is correct.

Given B, check if C is correct.

Given C, check if Output is correct.

As you can imagine, if the test fails, it becomes easier to figure out what failed, and hence to fix it.