The ego and smugness are holding things back.

TDD is not the norm in .NET and that is a fact. Certainly where I am in the world.

I started the thread after reading Roy’s article (even though it was not his point) and part of me was playing devil’s advocate to see what came back.

I love TDD and have loved it, especially after i now get regular reward.

But the learning curve was high, especially as the team I started using TDD with had no TDD experience.

A lot of dev.s where resistant when our first tests became unsuprisingly unmaintainable.

Not everyone can have or afford a coach and every blog I read is singing its merits.

The first time you stop a bug going into production because of your tests is the moment the green light goes on and you are hooked.

But, realistically, I see TDD as one step of a process — and not the first step either. I do believe there are more important ideas that should come first, or TDD will be incredibly painful. Things like good Object Orientation, Patterns, source control, one step builds, and making maintainability to be more important.

Back to a previous post of mine, sometime there are things that require us, as developers, to rethink how we make software. This is painful. Developers are smart thinking, it is hard for us to be convinced that what we have been doing is wrong — since we know it has been good enough for us so far.

Finally, I will completely agree with Roy (even tho he really just trying to sell something) in that we really need better tooling. We need better wording. And most importantly, we need better guidance.

Because we have bad wording, it leads to bad guidance. Because we have difficult tooling, we create pain in development.

But you also hit on one. Because we promote development speed over practice, we are not creating better developers. And as such, we are not getting beyond “good enough” software.

I’m convinced of the benefits, and continue to increase my test coverage for my own projects. Getting other developers to do it for theirs is difficult. In fact, I’m facing this right now. The argument I’m going to put forward is this:

* There are real benefits to TDD that will MAKE IT CHEAPER TO DELIVER SOLUTIONS.
* Most importantly, it encourages loose coupling, and that makes it much easier for us to change stuff. Period. We can roll with the punches.
* Also, we can introduce changes confidently, because tests will let us know when we break things. This is a *big deal*.
* Not testing is a “broken window”. You live in fear of the side-effects of change, and let bad code live on because it’s cheaper than fixing it. That problem escalates until the system finally requires re-build.
* Testing invites cheaper re-shaping, rather than expensive re-building.
* Depsite our doubts, if we NEVER *try* to get good at TDD, we will NEVER appreciate if these benefits are real. We just need to TRY it!

I’ll let you know how it goes!

Retrofitting a legacy project to work with unit tests requires more effort than using them on a *new* project. Do you have any projects coming up that could be good for getting on the learning curve as a team?