Chris Szurgot's Blog

I'm currently in the process of adding Unit Testing to legacy system (the word legacy here meaning code without Unit Tests) The system has a very interesting design with logic in all sorts of places (ASP.NET pages, utility classes, lots of logic in Stored Procedures, etc...) This has been a most interesting experience (The word interesting here meaning worse that fingernails scraped across a chalkboard), but fortunately rather instructive. I've learned more about the system in the last few weeks that I cared too <grin>

Working with a legacy system like this has been rather interesting. Because so much of the data is in the ASP.NET pages, and so many of the stored procedures require so much setup, I'm doing most of the testing in NUnitASP. This, of course, breaks a tenent of Unit Testing, because the full battery takes several minutes, (with less than 100 tests) and an individual test can take about 10 second because of tear down and ASP.NET page compilation (I'll be glad for ASP.NET 2.0 pre-compilation) The positive side effect is that I'm optimizing each page and query, to bring the time down, which helps quite a bit...

Of course, I also have to build up the test data, so every time I change the test data script, I have to run the full battery, then retrofit my data changes to include a new # of rows or value. Which tends to throw some tests off for no particular reason... Ugh... And takes several minutes.

Of course, the more I do all of this, the cleaner the system gets, the better the code coverage gets, and the faster the system itself gets, so it's all good.

But I'll tell you what, it's all the more evidence to start writing tests as soon as possible, and to put as much logic in a place where you can excercise it quickly. It's already getting real old to run these tests, and it frustrates my boss when I put up a quick change into test and have to wait 10 minutes for all the tests to run.