[...]For starters, the developers will improve their skills, not only in writing tests, but also in writing flexible and simple code. [...]

I was talking about it approximate 6 month in my company =)

The best way to start learning it on your own is to read Kent Beck’s Test Driven Development By Example… the examples may not be representative of the code you’re going to write, but it definitely teaches you the whole TDD mindstate. I’d also recommend the book xUnit Test Patterns.

And then you just need to start experimenting with it, and stick with it, even when it gets hard (and it surely will at first). But the important thing is to just ‘listen to the code’. If TDD hurts, you’re not doing it quite right yet and you need to investigate better options

Obviously, the best thing is to have someone around that is a TDD-master and can guide you in any mistakes you make, explaining what’s wrong and what would be better, and why that would be better anyway…

But what to do with developers (such as me) who are eager to learn, apply and master TDD, but don’t have any coach? Do you think it’s possible to “selfstudy” TDD? Any suggestions on how to handle that?

interesting stuff

and i definitely agree that you can’t expect immediate adoption of your entire (technical) agenda… i prefer to increase that adoption on a steady basis, but to take small steps while doing so. It just works better, for everyone involved actually

Couldn’t agree with you more. I work in a large(ish) development group (50+) with mostly .NET dudes, in the context of a command-and-control organization. Like many .NET shops, management has approached hiring, training, and project management practices with a mentality – one dev is as good as another, if it’s not from Microsoft it can’t be any good, etc. This has lead to some spectacularly bad legacy code.

To combat it, a small group of devs in our shop have been promoting TDD. We started with CI – I figure that developer testing is ALWAYS worth it, but you get so much more out of it in a team situation when you pair it with CI. Once we got underway with CI, we started adding tests as we had time, off-book, working a little extra when we had to. Over time, Management slowly recognized the value of developer testing, and has now begun to insist that developer testing be part of our project plans.

We still have a long way to go in addressing all our legacy code, but I can see lots of progress, both in the code base and in our development shop’s skill level. One of our most talented developers told me that he achieved his largest leap forward in skill level, particularly in design skills, by learning how to make code testable.

The biggest thing I’ve had to remember is not to expect immediate adoption of 100% of my agenda. I have to be satisfied with 2% incremental progress at a time. I’ve begun to think of our TDD skills and practices as a kind of technical debt carried by the group: we’ve made progress, and there are some things we have to compromise on in this iteration in order to achieve a deadline, but we’ll take care of those things in a future iteration. As long as we’re not going backwards, any progress in developer testing is ALWAYS worth it.