"I don't think we should be playing with our privates {variables} like that" - framework designer

= context =
It was noticed that we have too many setter functions to change private variables just to do unit tests. So we had a small meeting to discuss what to do about this.
Options:
- don't do the test
- ignore till another time (ie: keep the functions till its a problem)
- put the variables into a provider
- use reflection (the above quote was a reaction to this option)

My recomendation is a complete redesign if possible.

Testing should never have or need access to "private parts". Thats to coupled ;)

If you are using C# and your objective is to segregate usage as domain entities are not affected ever and as such are immutable you can make the entity's setters internal and in the assembly set internals visible to the test project...

Kinda dirty but better then opening up immutable entities

@mmcorreia it's in Java. Although it lacks the elegant get/ set as C#, the setter can still be protected, but they viewed that just as exposed as a public.

@Zyphuris55 a good unit test will treat the class as a black box. And in the best cases you even work through an interface. That way you can build a new implementation and test that it works without rebuilding any unit tests and there by avoid changing any thing.

But it usually requires all classes to be built to be testable.

All methods and properties must be either self contained in the class (no hidden dependencies) or dependencies need to be explicit and also preferably interface based to be mockable so you can provide testing data and avoid to complex setup in testing.

@Voxera the case of this test, which exposed other problems, is that we were saving a state (hasAudioFocus) to a static variable. But the variable was set privately within the class that's being tested.

The test in question was when passing an invalid channel type to the focus manager to request focus.
To test the channel blackbox style would require too much setup just for a response.

... then it turns out other tests were changing the static variable, which caused more problems.
Eventually resolved it by filtering the channel sooner which natively included channel tests (it's complicated).

@Zyphuris55 in that case, any test is almost always better than no test.

Code designed without though about testing usually does not lend it self to good tests and if it is just one thing to test a rewrite might be over the top.

The n the other hand, considering the problems you seem to have with it a rewrite might be the solution to both testing and solving the any problems ;)