Why Do I Like Test Driven Development?

Honestly, I have to say that I'm pretty novice as a TDD-developer. But I'm getting better and try to learn more all the time. And more I learn, more I love the way how it improves my code and makes development process easier and faster. In my opinion, it's more coders tool to write better code than a design method. And I say MORE. It's both. But when you start to do TDD, you still have to do good modeling, functional and architecture design and for that you need other methods, like DDD or BDD. (Lots of D:s around. By the way, in Finland we have we have artist whose nickname is "Big-D". He have been very popular since 1960's.) But that's another story. I'm just a simple code monkey (or software simian) who wants to write better code.

There are three main reasons, why I try to do TDD and wanna get better Test Driven Developer. And here we go!

1. It makes writing functional code faster.

When you write tests first, you always remember, where you were before you were interrupted and which part of your code works and which not. Test are you main "spec" for the code. Also, I could design code for someone else just doing tests first. If someone (or me) finds a bug, I can write test case for that bugging use case and when that test (and other tests too) goes green, I know it's ready for production again. I don't have to do any manual regression testing after that.

Also, when TDD has done right, you write small amount of code at the time, test it and refactor it. It's easier and faster to test few lines of  code  instead of hundreds at the time. After every TEST -> CODE -> REFACTOR cycle you have few lines of new "production ready" code. If you are in hurry, you can just write most important use cases and then go to next module. And continue next cases in next sprint. And you always remember, what you were doing (just read the tests). You might even notice that you only need those simple use cases in previous sprint. That's one big reason to do job in small chunks. You don't write any unneeded code.

And faster you can test your code faster you write more code.

2. It makes your development process more reliable.

When doing TDD right, you get regression tests for free. Ever have been in situation where you are thinking that what a hell broke my code? Ever, never? I know you have been. Now you don't have to think that anymore (at least so much than before). Just check tests that doesn't pass and you know the reason.

Also, have you ever been in situation where you couldn't been sure you have tested all your code? TDD offers solution for that too. Again, if done "right" you have tested every single line of you newly written code. Actually I haven't thought that before I got 100% code coverage first time in my life. That was odd at first, but very obvious, if you really think about it.

And more tests you run and write, more bugs and wrong behavior you find.

3. You get "a user guide" for free.

If you have written some library for other programmers or just for yourself, you propably want to document how to use it. Of course you could write comprehensive documentation (and you should in some cases), but if you write good test cases, you get that "for free". Usually if someone asks how to use code it's enough to tell that check unit tests. There SHOULD be an example code!

It's not science, it's craftmanship.