Unit testing vs API definition
January 21st, 2003
There is one thing I always get confused with when trying to make do some solid unit testing: how do you test private methods? AFAIU, unit testing should be done on chunks that are as small as possible. Those small chunks are most of the time implementation-specific. So good API design dictates to make them private. But then they become invisible for the TestCases...
I've just tried to develop some naming convention (make the real method doStuff() private, and define another method public doStuffTestHook()) to indicate that the public method is not to be used for normal use, but it still stinks. I've heard about some unit testing adagio "make everything public", but I don't like it, because I'll end up seeing somebody else using the method while she wasn't intended to.
I guess I have some serious googling/reading/learning to do about this. In the meanwhile, if you could send me some URLs, I'd be thankful.
Update I've been beaten by the FAQ again. Note to self: The information is out there.
April 21st, 2008 at 10:16 PM Hi, What about putting your test cases into a private static class inside the class to be tested? It allows you to test the implementation-dependent methods, while still having them declared private. We have a naming convention for these inner classes allowing us to delete them before we package the code for production HTH Fokko
April 21st, 2008 at 10:16 PM Embedding test code is not a good idea. That means you are shipping test code with your production code. In general, unit testing your public methods is sufficient, because they exercise your class. Your unit test should exercise the class as you expect your users too.