Driven to Develop

While still only a relative novice to TDD, I’ve found it to be amazingly helpful in building better classes and thus writing better code. With no one to guide me, I stumbled thru several articles and numerous examples before I finally started to “get it�. There has been quite a bit of trial and error that has caused me to alter the way that I code and I wanted to write about a couple of things that I’ve started doing that have been a tremendous help.

Throw out the debugger. Ok, not really, but that’s sort of how I’ve started to feel now. Actually, this has been the biggest shift in my paradigm and thus my actions (aside from the general need to refactor my classes as a whole). I used to write a small console or windows app that would instantiate the class(es), do some sort of setup, and then respond to my input so that I could see how my code was evolving/reacting. Well, this is EXACTLY what unit testing does. It’s simple, I know, but it still took me some time to get used to and to wrap my mind around the fact that I didn’t have to press F5 to see how things were coming, I just ran my tests. As I wrote more tests, I wrote more code to use those tests and vice versa. It was a wonderfully vicious cycle that led to some pretty enormous tests with a ton of pre-condition and post-condition checking.

Refactor your tests and fixtures as much and often as needed. While I had some extensive unit testing being done, it certain didn’t follow DRY and was sort of a mess to maintain. Enter SetUp/TearDown… While there are still some who debate their use, others seem to agree with me that using them will not only make your life easier but makes your code cleaner. Whenever I have a test that needs some setup done, I usually refactor that setup into its own private method first. Once several of the methods use that single private method, I move them all to a separate fixture and make the private method a “SetUp� method. As a side note, good naming convention is VITAL for good tests. I avoid using the suffix “Test� for them and try to make them as descriptive of what they’re testing as possible. This reduces the number of messages that I have to output with my Asserts – oh, and always try to adhere to OAPT for better testing.

Finally, for those of us who use log4net (if you’re not using it, start NOW) I’ve put together a quick little way to leverage it in unit tests (see example below). By setting up and adding a ConsoleAppender in my TestFixtureSetUp, I get all of my messaging within my testing GUI. I’m even able to control the levels and formatting on a per fixture basis. Notice the use of preprocessor directives to keep the logging out of my automated build scripts as well.

[TestFixtureSetUp]
public void FixtureSetUp()
{
#if !AUTOMATED && DEBUG
AttachConsoleAppender();
#endif
}

private void AttachConsoleAppender()
{
LevelRangeFilter rangeFilter = new LevelRangeFilter();
rangeFilter.LevelMin = Level.Debug;
rangeFilter.LevelMax = Level.Info;
ConsoleAppender appender = new ConsoleAppender();
PatternLayout layout = new PatternLayout( “%date %-5level %logger – %message%newline” );
appender.Layout = layout;
appender.AddFilter( rangeFilter );
BasicConfigurator.Configure( appender );
}

Which finally brings us to the testing GUI itself – learn it, live it, love it. While the NUnit GUI is passable, I’ve found Zanebug to be everything it is not. Plus it’s FREE – can’t beat that…