While I've heard lots about Unit Testing for years now I've never been able to force myself to implement them. I've always thought it'd take too much time. Time I could have spent writing code, getting work done. Then I go the project I am on now. It is a large project with a very tight deadline. A project that needs to marry different back end sources.

I've been put in charge of architecting the SQL Server back end and the entire middle layer for data access and business objects. I'm using many things I've not had a chance to use before at this scale (LINQ being the largest) in this project so there were many unknowns. The front end may not been done for a bit and I needed to test my data access functions. I decided to bite the bullet and write unit tests.

Normally I would write a small WinForms app to test the most important pieces. This is a dirty approach but it's fast. The biggest hurdle in my mind for Unit Testing was there was no quick way for me to implement and run the tests. Nunit is out there and has some VS integration but whenever I tried it I got confused of where I needed to go to get things done.

Now we have VS 2008 Pro with built in unit testing. While the testing framework included I'm told is decent it's not as good as Nunit. I personally don't care about that. The ability to go to the menu and create unit tests for methods or entire projects on the fly is a godsend for me. VS will create a project for you, include tests for any classes/methods you've selected out of all the projects in your solutions and then do it's best to create close to complete tests.

You can easily step into debug any test and run one or many tests. All the results are saved so they can be examined and compared. While the auto created tests need to be completed I am starting to find that writing to test my code interface is getting cleaner and more too the point. It's much more annoying to pass an object into a method that may only need one or two properties on the object. It's better to make the parameters basic types instead of complex.

The tests have to run against 2 different backends. While one of them will probably not change (the SQL Server) the webservice may end up being replaced. These tests will be invaluable for when that happens. We can then check to see if the new service is acting correctly and if not pinpoint the issues.