Jumping On The Unit Testing Bandwagon

posted on 2004-07-20 at 13:42:21 by Joel Ross

Yesterday, I integrated NUnit into our development process. It wasn't too painful, but we only have three unit tests so far. Nothing special, but it's a start.

I also added it to our build process, so the unit tests get run whenever a build occurs (which happens whenever a check-in occurs). Of course, in the process of checking in the unit tests, and configuring the build, I broke it for a few minutes, causing a few emails to go out to the team. But I eventually fixed it.

Anyway, we added unit tests because we had some small, easily testable tasks. Calculations and things like that. We are all new to TDD, so it's a learning experience for us all. I have long been interested in unit testing, but never found an opportunity to use it on a project. At my company, we recently had a project that was very successful that used a lot of the ideas we are using now (NxOpinion info can be found here.). So, as we dug into our project and the requirements, we discovered that we wouldn't be able to capture all of the requirements without an iterative development approach.

As part of that, we weren't sure when the best time to introduce unit testing was. Our team is made up of some fairly green developers. Introducing an object oriented design was a big step, as well as creating a shared component that can be used with both a public website and an internal system.

So throwing unit tests at them right away could have been overload. Of course, introducing it a month later is fine! So that's what we've done. It's a small step, but at least it's in the right direction.

Here's what we'll be testing right now:

1. Simple calculations
2. Anything that can easily be contained into small components, such as creation of objects and setting defaults.
3. Mehtods that use a database in a read-only fashion. On a side note, we are struggling through a good way to do database builds - more on that at a later time.

Here's what I would like to be testing eventually:

1. Methods that rely on writing to the database (being able to test the DAL would be nice!). I'll be watching Roy Osherove's post about Database unit testing and his attempt to build it into NUnit.
2. UI testing. We have some complicated javascript that we use and it would be nice to automate some of those UI tests, as well as being able to test ASP.NET controls.

Some day, we'll get there. Maybe. For now, we're slowly moving in that direction.

Categories: Consulting