If you don't trust your code, write another unit test that provokes side effects. Do that until you feel confident. Then go home and have a good night sleep. ..."
(Okay, it's me. I said that. I just thought it would be cool having a quote as an intro to this post)
That was the twitter version. What about the blog version? I think test driven development (TDD) is a good tool for helping you write code with high readability and a design with ease of use in mind (sometimes).
As a tool for testing (no matter what programming language you choose) TDD is overrated and quite often misunderstood. Probably because of the word Test in it, don't you think?
Before we start, I want you to don't care about stuff like code coverage, what frameworks to use and every line of code should have a corresponding unit test. That last thing is just nonsense. Think about the result, the code that actually will run in the production environment. The result is important. No matter how many nice unit tests there are, the result should be as simple as possible. Simple, as in easy to understand, maintain and refactor.
Simple is really difficult! I have failed with that many, many times (and still do, but never give up trying). What I have learned is that having a bunch of unit tests doesn't compensate for unnecessary complex production code. With or without unit tests, complicated code still sucks.
Also, don’t start the TDD journey by evaluating all those tools and worrying about continuous integration scenarios. Leave that for later.
Do it the Agile way: experiment and learn.
Take a look at the video and please share your thoughts about it!