As an ex-practitioner of TDD, it is time to give the credit it deserves, TDD is not worth it. As a developer, I need to spend as much time as possible writing code, I can’t be spending valuable time writing tests.
A few days ago, I was writing an endpoint to manage an online banking bank account. This required the account to exist in the database, a valid login/password, and data from an external microservice. There are too many things to set up mocks.
Writing automated tests is just a waste of time. When you are working on a critical feature, you can simply:
- Develop
- Test/Debug locally
- Set data in the local database
- Disabling the endpoint authentication so you don’t have to set data on the authentication system
- Put a breakpoint on the external API call to replace the data returned.
- Or, in case of time-sensitive features, like late appointments or payment reminders, you can wait for the reminders to kick in.
After each change, we can repeat the process above for our feature and all other possible scenarios we might have impacted. 20 scenarios to test? No problem.
As the process of retesting the application takes some time, you should only do this once a day or every couple of days. This way, you don’t waste time and can deliver more.
Confident developers
Tests are also a confidence problem; only developers who don’t trust their abilities have to write tests. If you are a professional developer, you can simply develop and push it to production, without even debugging locally, as you trust your abilities.
TDD is also not the only way to add tests. Even if I wanted an automated test coverage, we could just add the tests after the code was written. As a confident developer, I am sure to cover all the behaviours I wrote code for hours on end.
😂😂😂😂
As a parody as it is, this is based on arguments I’ve heard in the past on how TDD doesn’t work or is not worth it.
Let’s put a side the TDD practice, let’s focus on what’s the alternative?
- To manually test things?
- To delegate testing responsibilities and end up with a long feedback loop?
- To deploy code without testing?
- To write tests after the implementation and get partial coverage?
TDD is not a silver bullet, but I can confidently say it could be applied well and pay dividends in 80% of professional development cases. Exceptions don’t disprove the rule.
TDD is a skill set that you add to your toolbox, and you can decide when to use it as appropriate. Before throwing chairs at it, I recommend learning the practice properly. What is TDD? Who invented it? What are the rules that define whether you are doing TDD or not?
Top comments (0)