Unittesting private methods
- M
The current unit test guideline states:
While unit tests can point you in the direction of cleaner design, avoid the temptation of making design decisions solely for the benefit of testability. Use the unit tests as an indicator of potentially problematic design, not as the reason for the design. This includes setting access rights to what makes sense in the product code, even if it makes it harder to unit test. Java's security model is not exactly helpful here – having a friend keyword would have made it much, much easier to test. This can be handled somewhat by using reflection (all Field and Method objects can be made accessible with the setAccessible method), but it is more cumbersome. It could be interesting to extend a compiler with a @Friend annotation that makes the compiler convert outside access to private members into calls to the reflection API.
This section doesn't explicitly state how private methods should be tested (even though it is implied that reflection should be used). I personally dislike reflection as it introduces non-object-oriented code, introduces hard to understand method calls and defies the refactoring capabilities of the IDE. I think a nice pragmatic analysis of the different forces at work in this problem can be found here: Testing Private Methods with JUnit and SuiteRunner. I propose we use a reference to this page as unit test input to the developers, and leave the concrete solution open to the coders (and perhaps reviewers).