There are few things that help a developer maintain an application better than Unit Tests. There are a few things that make me nervous when I open a solution from VSS, but nothing makes me more nervous than a lack of unit tests projects.
I know the Unit Testing drum has been beaten for years, so instead of getting on a soap box and berating the Internet for not Unit Testing, I’m going to give you a story about a recent project I worked on, and how unit testing helped me succeed.
It all started last fall when I started work at a new client’s office. I opened the project from VSS and red flags started popping up. The first red flag was that this was a Visual Studio 2005 project and I was using Visual Studio 2008 (they did not install VS2005 on my computer), but this wasn’t really a problem – I was assured that they had standardized on Visual Studio 2008 now and the .NET Framework 3.5. The second red flag was the five projects in the Solution that couldn’t be found in VSS – each one ending with .Tests. I still don’t know why they were removed – but my guess is that they were removed because they didn’t pass.
The first thing I did was create a new Unit Test project. After examining source code thoroughly I created a test harness of unit tests of the existing functionality of the project. This is a very difficult and risky task since these tests are built under the assumption the current code works correctly! This is not a safe assumption when projects are missing from the solution. However, the fewer behavior changes I introduced to a program already in production use the better.
During this period (probably one week) I uncovered and fixed many bugs. I re-factored a lot of code. I did more testing.
Then I added my new functionality, retested and it worked.
I added more tests. They went from red to green.
My confidence grew with each little green light.
I added integration tests to the unit tests. These all passed.
Eventually the program was ready for deployment to the testing server (UAT – User Acceptance Testing) – a model of the production environment. And I was confident! My tests were passing!
This is when everything went wrong.
The Problem? Updating to the .NET Framework 3.5. Of course I had been misled when they assured me that they standardized on 3.5 – the production environment was still very much in 2.0 (and I was strongly assured they would not upgrade – even though I hadn’t asked).
The Solution? Unit Testing! I had extensively used the new productivity features of 3.5 like LINQ and Extension Methods. It took some rewriting and work but I was able to revert and rewrite everything back to 2.0 compatibility in one afternoon! The only reason I could do it so quickly was the unit tests I wrote that told me the functionality was still there and working in the old Framework. It took more time to find another computer with Visual Studio 2005 and the .NET Framework 2.0 installed (and not the 3.5 installed at all) than it took to rewrite the app to the older framework version.
There were more problems that were solved with more testing, but Unit Tests saved me a lot of time and guessing. There were some other things that could have made the project more successful such as better communication with other developers and the production team. Those issues were beyond my control. But I was so glad I had those unit tests, they saved my bacon. They gave me confidence in the completed software. The Unit Tests were also something I could show my client, the maintenance teams, and the testing teams in terms of functionality assurance for them.
Ah success! A new project! Another Solution! …and guess what? No unit tests. *sigh* Here we go again! 🙂