TDD is dead?

Recently there’ve been more and more articles with a similar idea: TDD is not a thing anymore. I don’t know, maybe DHH has raised a waive with his iconic “TDD is dead” and younger programmers hiped it across the internet. Or perhaps there are so many controversial articles about TDD that anyone with name has to make a decision about TDD.

I’ve always thought that TDD/BDD is the only right way of writing software (especially when you don’t have a compiler on your side). With proper tests you’re sure your application is working right, even if it’s your expected behaviour, because without tests no one knows how application is working.

Anyway, articles against testing appear regularly. Someone tells you QA will be enough, others that a customer doesn’t want to pay for tests, and they are both wrong because this is not about customer’s want, it’s all about working software.

I’m not going to tell you why you should write tests or use TDD methodology, there is plenty of information out there. I’m going to tell you why it’s a good idea to consider using TDD for an existing or a new project.

Tests are the playground

Let’s assume you’ve got a huge project and you have to support it (with tests). You need to add some new functionality. What are you going to do? Obviously, you’ll try to read code, make connections in mind, try to make some code in console. But how much time will it take?
Or, you can run tests and drop a debugger where you think you’ll have to add new functionality, and then inspect objects and current state of objects.
Moreover, test environment is safe for any destructive behaviour, neither DB nor object connections will be broken.

Another good use of test integration with 3-rd party APIs: setup test environment, get sandbox from 3-rd party and you are ready to inspect request/responses. It’s always easy to send real requests and get response rather than read documentation :)

Tests are good for starting a new task

Sometimes you get such a huge task, that you don’t know how to start it. It consists of so many requirements that it’s even hard to start.
Here come integration tests: you write feature tests which describe how your system should behave in which situations and then, step by step, implement code from the outside.

Tests make you API consumer not only producer

When you write your code with test-first methodology, you become a consumer of your API not only a producer. When you use your API first for testing, you know how this API will be used and think about better API design.
On the other hand if you write code first, then you write tests just to fit your code. It’s useless.

Tests - litmus paper for your code

Hard to write tests for code? Guess what? This code is bad. Need a complex object’s state to test small functions? This code is bad (and so is the architecture).

And the opposite - if the code is easy to test, most likely both code and architecture are good.

Conclusion

TDD/BDD is a great tool for your code and API design. Tests help to think not only as a code producer but as a consumer, therefore to build a usable and predictable application API is easier.