What? Good Test Coverage Does Not Always Mean 1 to 1?
26 Feb 2013
As a student of testing, aiming for thorough test coverage, it looks like sometimes I may be more than covering the mark.
While working on my java web server, I found myself happily writing my tests. I did notice however, that when I would set methods to private, I was not able to test them. (noob) My junit tests would fail. :(. Of course I need tests! My solution... make all the things! but make them all public!
I continued on with this method although I wondered how others were able to have private methods. Part of me wondered, "Are they not testing? Shame on them." ;) All the while, the more things that I made public when I could see that they didn't need to be, the more exposed I felt and the more I was having flashbacks about Doug giving me a lesson "not to expose my privates"(haha.) Oh, the early Tic-Tac-Toe days.
Anyways, after reaching the point where I was in my main method working on testing parsing some args, I noticed that my fail safe method of just making things public came grinding to a halt. The introduction of something being static was new to me and since main was, and had to be, I was on new turf. (More on that in my next post)
Anyways, I started talking to Doug about testing this and a couple other things. Through chatting and working together, I realized two things.
1.Through some refactoring and reaching a more elegant solution, many of my tests were now redundant. I was terrified to delete them. Somewhere along the way, I had taught myself that more tests were better.(I now see the error of my ways.) :)
2. 100% test coverage or through test coverage does not mean 1 test for every method.
Consider this... You have a method that does something(that would be useful) and you have another method that you call from inside it that does a little bit of work for the first method. I would usually write a test for both but that is unnecessary. It is redundant. If you write a test for the first method that calls the second method(that contributes to the result of the first method), you are in fact testing it.
So you can see, the only benefit isn't just less typing. Now we can now go back and make private the methods that do not really need to be exposed while cleaning up tests and maintaining coverage.
Boom shaka laka!