bdd

Test First? Or is that new legacy code you just checked in?

Chris Canal — Fri, 09 May 2008 14:33:54 GMT

Quote:

...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:

Quote:

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.

Handy HttpPostedFile & HttpFileCollection abstractions

Chris Canal — Wed, 23 Apr 2008 19:18:43 GMT

I've just upgraded to the latest version interim drop of the MVC framework and MVC Contrib (which I can't seem to build from source using NAnt...). Everything appeared to be ok, except for one thing: a controller action that uploads a file was now throwing an error:

cannot convert from 'System.Web.HttpPostedFileBase' to 'System.Web.HttpPostedFile'

After a few seconds of confusion I quicky dawned on me that this might be a very good thing. A quick look at the System.Web.Abstractions confirmed my throughts, it now contained abstractions for HttpPostedFile and HttpFileCollection!

Color me happy, the only code I couldn't get covered was Actions that handled file uploads.

Resistance to TDD

Chris Canal — Thu, 27 Mar 2008 11:21:40 GMT

I've been developing with Test Driven Development for awhile now (more in the form of Behavioural Driven Development) both in and outside of work. I've recently started a new job where TDD isn't used and I've been showing the other developers how I use it.

If you have ever read a TDD book, you'll know every argument against TDD they have given to me:

Adds too much time
Not beneficial for the client
Makes things complicated
It's to be used by people, not machines
Bad experience

Adds too much time
For me, this smells of a lack of understanding of the TDD process. Granted, I have noticed a slight increase in development time when I shifted to TDD. However, the time added was no where near the time I saved when it come to debugging at the end. In fact, I spend very little time debugging at the end of a project, and when I say little, I'm talking about very little. I don't feel careless or reckless by doing so, the confidence I gain from implementing a comprehensive test suite is unrivaled and I know my code will work exactly as it should.

For me, the natural evolutionary nature of developing with TDD leads me into integration development very early, meaning I also save more time when it comes to implementing the code in a real world situation. Using mocks means I can still keep the tests atomic and isolated. I've recently started using SQL Server CE when I want to test database interaction, so tests can now run without any database setup. And in a Continuous Integration environment this saves so much time it's unbelievable, no one in work will believe me

The real time saver though is maintenance. This comes in two forms: lower defect count and being able to locate problems quickly and easily, and being able to work on them in complete isolation.

Not beneficial for the client
I've found it easier to hit very tight deadlines with TDD, and can give far better estimates. And with a lower chance of defects being means less maintenance work from the client and more real paying work. It also gives you the ability to quickly and easily add or change things. I'm talking about crazy quick and easy, especially when using a tool a refactoring tool like Resharper.

These will all lead to clear benefits for the client and the business. You will be able to give better estimates and because TDD will save time and effort, you can deliver a product ahead of time and under budget. The ability to quickly made large changes means you can deliver them to the client quicker and cheaper.

Makes things complicated
Like everything else, there is a learning curve to TDD and when shown the resulting code, my colleagues of insisted it was complicated. I find this argument a little hard to get my head around. I've found my code far easier to understand and work with. I've also found it adhering more to common OO practices. I've found it far easier to see where a pattern could apply, and been able to quickly refactor code to use them. In doing so, I've gained a far better knowledge of patterns and their application.

Yes, I have some fairly complicated tests but that's because I'm aiming for as high as possible code coverage with the least amount of dependencies possible. I do use mocking frameworks, Inversion Of Control containers, but you can still create a comprehensive test suite without making things too complicated. Another argument for this was junior developers working on the code. This I can kind of see the point of, but some mentoring and knowledge share will quickly get the junior developer to a level where they can at least edit tests and add basic ones.

It also raises the question, if the junior developer can't understand the tests and their not willing to learn, should they really be working on the application?

It's to be used by people, not machines
I really laughed when I heard this one, it really highlighted a lack of understanding what Test Driven Development is. When I'm trying to explain what TDD is, I sometimes tell them to think of it as Test Driven Design. TDD has more to do with creating clean, well thought out code that testing. Yeah, I've got a lot of confidence in my tests when it comes to testing an application at the current cycle, but TDD is only one layer of testing. It will never replace proper QA testing, and its not aimed to do so.However, I still automated a lot of UI testing. Using WatiN, I write tests aiming to cover all the possibilities and while it's not a person, I've at least got a safety net to rely on whenever any strange UI bugs crop up.

Bad experience
One of the developers has had a fairly bad experience with TDD, but this too still seemed like a poor understanding of TDD, both from the developer and the developers that had implemented TDD. Like everything, what can lead to good practice, can lead to bad or misinformed practice.

But you shouldn't write something off because of one bad experience, it just takes some courage to keep going.