Geeks With Blogs
Chris Canal A Scottish .NET Developer
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. Posted on Thursday, March 27, 2008 11:21 AM development , tdd , bdd | Back to top

Copyright © Chris Canal | Powered by: