Restless C#ding

Admittedly, I'm very early in the process of getting a full suite of automated continuous tests going against an app I'm working on writing. Currently it's only involving NAnt running NUnit tests on checkin.

Jeremy Miller gives some great pointers in this post on how to extend that. Inversion of Control (IoC) is a fundamental basis for testing interaction, as well as behavior tests through WATiN testing.

After adding many unit tests, today I found myself cheating a bit. I'm attempting to retrofit tests to classes and methods that are responsible for way too much. So picture class A which is not written through TDD methodology. The new functionality in class B is being written through TDD. What I was able to do was to write good (-ish)  tests for class B, but for class A, I found myself writing way too much setup code.

I'm curious how the process will work out, but I wound up writing somewhat long unit tests to meet the point of the test. The tests are reliant on actions A, B, and C occurring before the actual thing that was being tested. So I wrote some helper methods, but I worry about one thing breaking taking down the tests like a house of cards.

This seems like a no-brainer for more of a BDD style of testing, but only more investigation will tell. One bright note is that code coverage went way up, since tests touched a large number of deeper library methods.

What is it about that last thing you want to get done before leaving that just refuses to make sense & work? You come in the next morning and it winds up taking 10 minutes.

That was the case for me today while trying to reconcile LINQ and a Unit Test. For some reason the code works perfectly in the web app, yet refuses to work (or even give an exception) when seated properly in a test fixture. Hopefully I'll update this post tomorrow stating it was something obvious.

Update: Sure enough, it was. I realized that data contexts were being cached in HttpContext, which won't work in libraries where unit tests are being run (they're not part of a web app after all!). A little Thread Local Storage, and my woes are no more.

In order to make writing unit tests easier, Ayende Rahien has come up with a mocking framework for hte .NET framework. These mock objects "pretend" to implement interfaces, and display expected behavior for tests.

Some resources available for learning the basics are:

• Wikibooks "How to use Rhino Mocks" 
• Using Rhino Mocks to Unit Test Events on Interfaces
• Ayende's Rhino Mocks documentation wiki