How Testing Improves Design

Recently in work we have been looking at our testing strategies for a web app we are currently working on. The application itself is a Spring MVC java web app, and there are several challenges that we have faced around things like how to best test the persistence layer, testing the UI, mocking HTTP requests to test the controller calls, but today I was looking at testing a Service class that was used by one of our controllers.

The first challenge (as I was going for a bottom-up approach, starting with the most granular methods to test) was what is the best way to private methods. A little bit of initial research showed many people suggesting using reflection to test private methods, however, having spoken to the team's "test architect" he expressed a dislike for this approach as it resulted in failures at runtime (read test run time during build/package with maven) as due to the nature of reflection, if the contract of the class changes this is not flagged up with compile errors in your IDE. His suggested approach was just to make the methods public.  Clearly a bad idea and goes against basic OO principles, so I decided to investigate further..


On further reading, I started seeing a few people making claims such as "When I have private methods in a class that is sufficiently complicated that I feel the need to test the private methods directly, that is a code smell" - and I thought on this for a while, and looked at the code that I was testing and agreed.

Whilst the test architect had been wrong to suggest making all the methods public, I think it's fairer to say that you should be able to fully unit test a class with confidence only using public methods, these after all are your entry points, or contracts with the rest of the application, and your private methods are just implementation details - As the poster above states, if the private methods are so complex that you feel you should test them, then your design is wrong!

We all know about Principle of Single Responsibility and all that, but due to the constraints under which the application is being delivered, the service class had lost its way and many of the large, cumbersome, private methods shouldn't really have been there at all and needed to be refactored in to other relevant objects, where they could be exposed as public methods in themselves (obviously also helping reuse).  This is a common problem and easy to slip in to, you start off creating a Service class to perform some function, and as you develop it, the scope widens and more and more functionality is needed for this task, so it is easy to think that this functionality should be included in the same class, it is after all core to what the class is trying to achieve. However, you need to take a step back, as in this case during the testing, and analyse the class, does the functionality really belong in the class? Is it directly and singley contributing to the goal of the class?

With a quick nip and tuck the daunting task of mountains of private methods had all but disappeared and as well as that I could leave happy that the code was cleaner and more maintainable for it!