About the harm of Test Driven Development

About the harm of Test Driven Development

Artem Zakharchenko, testing specialist and author of the testing library MSW with 15K stars on GitHub, shared his thoughts on Test Driven Development.

Here’s the truth about TDD (Test Driven Development).

TDD is a bad practice. She was always wrong. It is wrong by definition. Its main merit is the encouragement of testing, but it ends there.

TDD means writing tests before writing code. So what’s wrong with that? You write tests to describe the intent behind the system – how you expect it to behave. TDD largely implies that you need to know how the system behaves before implementing it. You must know what you are doing.

Most of the time you don’t know it. All the developers I know don’t know this beforehand. I don’t know this in advance. In fact, I can spend several days experimenting, writing MVPs, until I start to understand a little bit what the parts of my system should be and what I expect from them.

I don’t see TDD as a viable approach in fast-evolving systems like the web. It can make much more sense when writing system software where very little changes from project to project. This is the complete opposite of what you write on the internet.

The downside to TDD is that I’ve seen teams get frustrated if they can’t follow it. And then they abandon the whole idea of ​​testing because TDD is so widely associated with it. Instead of encouraging people to test and showing them that software testing can be fun, this practice locks them into pedantic constraints that no engineer can follow.

I don’t follow TDD. This does not mean that I do not write tests. I write a lot of tests. I develop prototypes, iterations and tests.

Prototype. I give my ideas space and let them breathe without worrying too much about testing first. I experiment, change things, break things, put myself in the user’s shoes, and design APIs, behaviors, and expectations. Like I said, it could take a while.

Iteration. I spend this time making sure my system makes sense and meets the requirements (which may themselves evolve and change why I’m doing it).

To test. After all, I write the tests. It became an integral part of my process. I can’t imagine not writing tests.

Of course, there are exceptions. If I write a simple I/O function, I don’t need to spend a day trying to figure out what it does because that’s all it will do. I can write some unit tests for her from scratch. But most of my work (and, I’m sure, yours too) are not simple functions. This is complex logic that takes time to set up. If I strictly follow TDD, I’ll spend time writing tests that I’ll end up throwing away. It’s useless and won’t help me find confidence in what I’m creating.

Do not despair. Apply the practices that work for you (even if it’s TDD, so you don’t lie to yourself!). The bottom line is that testing matters. It always mattered. Developers have been testing software since the 80s, I think. You should too! I will do my best to show you that testing can be affordable and exciting.

Related posts