You want to use Test Driven Development but your fellow developers refuse it because TDD is for nothing then it’s time to convice them. If you need some good arguments then take a look here:
Robert “Uncle Bob” Martin compiled a list of counter-arguments against the most common anti-TDD arguments
Happy reading and argueing…
Hy Urs,
Thanks for pointing this out. And we all know why the series of this blog posts from Uncle Bob are so important. But unfortunately people like our famous Joel who loves duct tape programmers (see http://www.joelonsoftware.com/items/2009/09/23.html) might never be convinced…
Daniel
@Daniel Marbach
True, true. There will always be developers who are not open minded enough to give a different approach than theirs a chance. And they often fight others to make sure that they themselves do not look bad.
Why am I reminded of politics while writing this, hmmm?
But what do we care about others? As long as we have a set of disciplines and tools that help US get things done, everything is okay for me 🙂
You can’t really do TDD if you work for a client, because clients don’t pay for it and they require everything to be done as fast as possible.
@Jack
Jack, thanks for your comment. There are really a lot of developers that think the same way as you. However, I disagree 100%. Let me explain why:
First of all, there is always a client. Even in my open source projects I have a client – myself. I don’t like wasting time in my spare time, therefore I really take great care about the time I invest in a feature I develop in my open source projects. If you have paying clients, they surely doesn’t want you to waste their money either.
While it is true that my clients do not pay me explicitely for doing TDD, they pay me do deliver them a working software as fast as possible. WORKING! TDD is just a tool amongst others to get my code working. Therefore it is acctually no different that a compiler producing errors and warnings. They spot you at problems. The same does TDD.
There is no “coding first then unit testing” in TDD. It’s an integral part of the development process – production code and test code are created together.
Therefore, TDD works for us – we gained development speed (e.g. much less debugging, parallel development, better extensibility and changeability) and we reduced maintenance cost (bug fixing) dramatically. This are just facts from my projects done with TDD. You can ask anyone from my team, they will all say the same.
Once again, it works for us, if it does not work for you, then keep your hands away BUT DON’T POLLUTE the internet with wrong facts about TDD without even giving it a try.
Sorry, if my words got out a bit harsh, but I’m really sick of it 🙂