Thursday, February 7, 2008

TDD Doesn't Make Development Take Longer!

Hi people, tonight I'm thinking about the conception that Test Driven Development makes your project take longer. I googled this post from Jeremy Miller and found it to be based on experience and really match what i've found on my own programming experience.

Some people say that a project can take longer cause you must write and maintain more code, and each time you suggest to include more quality in your software through tests you hear the same objections... but why is that?

Well, I think that is really a natural reaction and seems logical if you haven't developed the test-driven way (red-green-refactor). Some people think they have done TDD but they have just coded automated tests, but TDD is about design and continuous design. If you design the test-first way you are going to finish your code in a faster and better way... that's just a non issue for me. Your code will do what you supposed it should do, no more, no less. Why don't you try yourself? This is a pragmatic issue, if it works why don't we apply it and enjoy the benefits?

Jeremy Miller lists where he thinks TDD cuts development time, and I concur:

- Design
- Debugging
- Fixing bugs
- Testing

Let me add a few, IMHO:

Maintainability: When you develop the TDD way, you can refactor and change your code anytime and just enjoy the simplicity of good code and your unit tests are a safety net. That resumes in few development time and make programming more fun. Also, you can focus more in adding value to the code by reducing technical debt and improving your design cause good tests are you allies.
Trust in your own code: Since the days I started thinking and with TDD I trust much more in my code and feel more proud of it. I can even invite you to take a look any time and even make changes with confidence that my tests validate yours!
Trust in others code: if you honestly did TDD and you trust me your code for working on it, I'll feel very secure that your code will be simple, understandable and open to refactorings. We work in team environments, people come and go, and our code should be always hight quality. We'll save ourselves so much pain...

BUT, (and this is a big BUT), you'll enjoy all that benefits if you're honest and mindful about TDD. Please, don't do it as just a requisite. And PLEASE! Don't say that TDD is an overhead to software development if you haven't given yourself to learning how to do it and practicing for a little while. I can assure you, you won't regret.

If you want, take a look at this Introduction to Test Driven Design (TDD). Enjoy!

No comments: