Ok, so the time has come to write tests. You want to conform to Test Driven Development. You’ve been taught the power of Design by Contract, but abysmally, you learn that apart from Eiffel with its postconditions, preconditions and invariants, you are going to have to setup your own test fixture around your C#/Java code that does similar things. (see Design by Contract Framework).
For public and protected methods, it is easy to access those calls and write unit tests around them, but private methods are well, private. You could place assertions at the start of your method (emulate preconditions) and exception throwing at the end (emulate postconditions) in those private methods to implement pre and post conditions but your fine grained unit now becomes a little bloated and hard to read and you still lack a test fixture that will run that private method on demand and let you know if the outside world has changed its mojo.
I believe that this comes down to design. How you design your classes, which methods take what responsibilities and delegate to other classes. Some clever cookies come up with even more cleverer designs that reduce code and provide hooks into your methods to test them from the outside looking in. The new guy at work keeps telling me about the patterns he implements, his class structure because of those patterns and how all his code can be easily tested. I watch with interest, how he can pass the model around freely and decouple the functions and indeed learn that:
Good Design makes for Greater Effeciency, and
Good Design makes for Easier Testing which makes for Greater Efficiency. (and so on and so forth!)
See here for an example of what I think he is referring to.
So without being a Design Pattern ninja, I’m left to trawl the net for the basics (dont worry, these design patterns that allow for easier testing wont be left alone for long, believe you me), but there are some alternate means of writing unit tests for private methods.
With this approach comes the debate about whether you should actually write (or try to) Unit Tests for private methods. Should your self contained unit simply be tested by its public interface, or should you go hardcore Design By Contract and test each function to its contract; testing it to the letter of the “coding standard” law in your development house of jurisdiction. (Apart from being a nerd, I also am talented in the art of dorky jokes)
One thing I have learnt is that if you haven’t designed your class correctly, you will find it difficult to write unit tests to begin with because they will be hedging in the direction of integration tests (as in too much, too many hands in one spot). If your tests are long, perhaps the functionality should be broken down and hidden (too many methods not doing enough, work shared unevenly, meaning more setup code to test some methods)
Your private methods should be small helpers and as time goes by, perhaps, and this is only my opinion with limited pattern knowledge, refactored so that they are pushing the work out to a factory or other builder and now you are just testing the building of a correct object that functions as expected, rather than an object being correct overall.
To summarise the approaches of unit testing private methods:
1) Change the access modifiers to protected and build test classes that work in the same package as the methods. This kinda stuffs up your whole class
2) Use reflection to find and run those methods. Bad thing is if you refactor, you have to change the strings that are the method names manually.
3) Don’t test your private methods. Test the public ones that call said method, ensuring as best as possible to create all cases against the private ones.
4) Redesign; a new design pattern, a new approach to feed your supporting objects in.
So there are a plethora of links and resources I want to share with my Firefox bursting at the seams with tabs, so lets go:
– How to Test Private and Protected methods in .NET provides a quick overview about the pro’s and con’s of testing private methods and delves into the methods to circumvent this protection. It waives the flag for using reflection of your private methods to test, but this comes at a cost of any renaming refactor requires a code change to the string by which you Emit the desired private method to test.
– For Java affaciodos, Testing Private Methods with JUnit and SuiteRunner provides the Java perspective and the same techniques that can be applied to .NET can be applied to Java also. Again reflection is the flag most waved but provides a balanced look at the others. Bruce Eckel (of Thinking In Java fame) also plugs this site here (to which I was led to his own site and got distracted about his pages about the greedy book publishing industry)
– If you are lucky enough to have the Visual Studio Team System edition for Testers, it appears to do all the hard reflection work of testing a private method for you automatically, but does come with the same creveat of reflection
If the signature for a private method changes, you must update the unit test that exercises that private method. For more information, see How to: Regenerate Private Accessors.
– This link is an against for the testing private methods debate.
– This is another against which mentions C++ friends and the more techy details of assemblies and changing the accessor from private to protected internal, so I thought I’d include it here (i wish i had friends in C# right now, hehe)
– And here is a well written for unit tests on private methods.
– Apparently NUnit 2.4 will provide a Framework Extension to test private methods (http://nunit.com/blogs/?p=25)