posted on Wednesday, August 17, 2005 3:04 PM
by
richardSlade
To unit test private methods, or just the publics
Hmm, I see that there is often debate about what should and shouldn't be tested with regard to unit tests.Many beleive that it is enough to test all the public methods of a system while others are sure that every method should be fully unit tested. This, for me at least is a tough one. There are, I think many factors to consider.
So, what are the factors involved? - Here are just three.
Pressure from the business to write production ready code. Yesterday
The difficulty in testing private methods
Public methods are exposed interfaces, therefore if these are fully tested, why test what they call.
It doesn't quite sit right with me that each part of the system isn't tested. After all, there is no more reason why the private methods shouldn't break than the public ones. Why should private methods suffer the loneliness of a test-free life. On the other hand, these are hidden chaps that are never exposed to our clients. All those proud public method chaps are sitting on the front line and happily calling the privates for help when needed.
Also, to test the private methods seems like it's going to add some overhead, certainly in time and resource. If our public methods are properly, no really properly tested then we would also be duplicating some of the testing, surely.
In my experience, there is always a balance to strike between doing the best possible to ensure that we write robust, maintainable and bug free software and resigning ourselves to the fact that it's the busness that pay our wages and if we can test what we expose well enough then we are saving ourselves time and overhead while still delivering on-time and within budget.
By now you should know which side ofthe fence I sit on. Test all your public interfaces, but do it well.
Cheers
R