Geeks With Blogs
Chris Canal A Scottish .NET Developer
...legacy code is simply code without tests. - Working Effectivly with Legacy Code - Micheal Feathers

I was discussing testing with a friend the other day, mainly Test Driven Development and we got onto the topic of new code without tests and retrofitting them. The first thing that popped into my head was the above quote and the following:

Code without tests us bad code. It doesn't matter how well written it is; it doesn't matter how pretty or object-oriented or well-encapsulated it is. With tests, we can change the behaviour of our code quickly and verifiably. Without them, we really don't know if our code is getting better or worse.
You can imagine his reaction after I shared this with him.

However, I completely agree with that Micheal is saying. Any code without tests, no matter if it was written a few hours ago or a year, is bad legacy tests. Retrofitting tests on the code then becomes a task with dealing with legacy code. True, you will probably not have as hard a time dealing with new legacy than you would older legacy code, but the main issue is that your still dealing with legacy code.

Once the code is written, retrofitting tests isn't Test Driven Development. Your not designing the code to make your tests pass, your designing you tests to ensure behaviour of exisiting code, and this means legacy code. Would I recommend retrofitting tests? No, I would give it a miss, concentrate more on integration testing. Add unit tests on the code when your editing it, as you would with, you guessed it, legacy code.

My Code isn't bad because it doesn't have tests!
It was never my intetion to insult friend, but the fact still remains that I agree with the above quote and view any code without tests as bad code. The key aspect of a good application is not how cool the code or how slick he UI is, but how maintainable it is. And not maintainable for you, but the developer after you.

Over the years I've worked on some really nice applications. The UI is nicely design, the customers are happy with how everything works, but without tests, maintaining it is magnatidues more difficult than an application that does.

How can a new developer to an applicaton confidently make changes if there is nothing to verify the changes? Sure, they can sit and manually test the UI is doing as it should, but what about the subtle bugs that can be introduced? The side affects of a change that can appear somewhere else in the application. I've experienced nasty side-affects without tests before, and when they are in an unrelated section of the code, it can be a nightmare without to track down.

Un-legacying your code
As I said before, there isn't much point in retro-fitting tests as an actual task. Concentrate on adding tests whenever your going to be working on an area. The goal is to introduce confidence building tests and either maintain behaviour when refactoing, or ensuring you don't break anything when changing behaviour.

Without TDD, your probably going going to have to break dependencies. The one common issue I've come across when helping people deal with legacy code is dependencies and interaction with the database. if your test hits an external resoruce, then its not a unit test. A unit test should be small, quick to run, atomic and run is isolation. This makes it difficult to add tests to code that uses things like LINQ to SQL as they are very tightly coupled to the database, trying getting a test quickly and easily in a test harness. Anything that ties your application to a data source is not a good option for maintanability.

It's also detrimental to running the tests. Having tests that hits the database can be time consuming, time consuming tests == test that will probably not be ran and then your back to writing legacy code.

Errr... the point?
So, the point? Well, learn TDD. I know I do keep going on about this, but I do have a good reason. TDD is new to .NET, it needs more people to take it up. Microsoft has just started with the MVC Framework, so momentum is growing. But it's the troops out in the field that need to pick it up too. Trust me, when you get into the full swing of it coding is exteremly fun again, even the boring tweaks. You've always got a safety net so huge refactoring or changes hold no fear, late requirements from a client are no longer a reason to moan or a worry.
Posted on Friday, May 9, 2008 3:33 PM development , tdd , bdd , | Back to top

Copyright © Chris Canal | Powered by: