Test-driven development (TDD) has been around for a long time. Many developers have seen its tremendous benefits. Yet many also decry it as useless or even harmful. I can only share my experience, and I consider it one of the most useful tools a developer can have.
There are many arguments opponents of TDD make: "it takes too long to write the tests first", "it's tough to write tests without knowing what the implementation will be", or "I can write tests after the implementation and there's no difference", among others.
In my experience, the learning curve is not as steep as people think. Though I admit, those who have been programming longer seem to have a harder time learning test-driven development, because it requires unlearning old practices and learning new ones. And it can be a pretty radical change to their workflow. But TDD isn't slower or tougher once you're used to it. And I believe there's a world of difference between writing tests first and writing them after.
Test-driven development is not solely — perhaps not even primarily — about writing tests. Rather, test-driven development is an approach to problem-solving that begins with the end in mind. And it is a practice that consistently reinforces creating high-quality code by working iteratively and by improving design through refactoring. Tests are merely the means to those ends.
But even if all the benefits of TDD were described in detail, and even if the greatest orator gave a speech as to why you should use it, it is tough to truly convey just how useful TDD can be until you've practiced it. So I will only tell you that TDD changed my career for the better, and I think it can yours too.
Since you're reading this, I hope you're interested in giving it a try. Thus, my plea with you is just this one: stick with it. TDD is a skill, not just something to be learned by reading. And as such, it requires practice.
So give it a real chance of working for you. And I promise the benefits will far outweigh the investment. And if, in the end, you still find it useless, you can always revert to your old way of doing things. But I do not think any who practice it earnestly for even a fraction of time are unchanged.
This book is about learning TDD by practice. Throughout the book we'll build a real chat application using Phoenix. But first, we'll briefly cover what is TDD, why it is good, and we'll go over a high overview of the approach we'll use to build our features. That's all in the next chapter. So without further ado, get ready, and let's get started!
This is a work in progress.
To find out more, see TDD Phoenix - a work in progress.