Why we dont like TDD

https://oneuptime.com/blog/post/2023-11-21-why-we-dont-like-tdd/view

by ndhandala • 11 months ago

3 6 11 months ago

Fr3dd12• 11 months ago

I had quiet a ride myself with that topic. For years my opinion was, that I dont want to, as the auther here suggests as well, go with tdd as long as I dont know exactly what I need. Than I switched over and used tdd for everything with a more regid (interface) design upfront. Nowadays I use tdd from the integration side and only add unit tests later or case by case when I think its usefull. A really good ressource is "Growing Object-Oriented Software, Guided by Tests"

perrygeo2• 11 months ago

tdd from the integration side and only add unit tests later

This is where I've landed as well. Unit tests are for locking down the interface, preventing regressions, and solidifying the contract - none of which are appropriate for early stages of feature development. Integration tests are almost always closer to the actual business requirements and can prove direct value - ie only once the integration works, then lock it down with unit tests.

I've also toyed with a more radical idea: don't check your tests into the git repo. Or at least keep the developer tests separate from the automated tests. Think about it: what rule says that the tests used in development should go directly into the CI test suite? One is designed to help you navigate the creative process, the other is designed to prevent regressions. I think we do a disservice by conflating the two scenarios into one "testing" umbrella. During TDD, I need far more flexibility to redefine the shape of the tests (maybe it requires manual setup or expert judgement or ...) and I don't want to be hampered by a (necessarily) rigid CI system. Dev tests vs CI serve two completely different purposes.

Fr3dd12• 11 months ago

Interesting idea but what exactly is a dev test for you? And when does it qualify as a ci test?

FrankWilhoit• 11 months ago

Think of the reasons why we have to treat development as an iterative, experimental process. It is because we are disambiguating requirements that ought not be ambiguous. The value of TDD is as a stick to beat the business with: the proof that your requirements are not good enough is that there isn't enough information to write the tests.

MoreQARespect• 11 months ago

first the developer writes a failing automated test case that defines a desired improvement or new function

If you TDD at the highest level that makes sense, with a test that mirrors the requirements in the form of a user story rather than the implementation (e.g. of a new function) most of the comments in this article dont really make sense.

Yes, if youre not sure about requirements its too early to write the test, but it's also far too early to be writing any production code.

There arent any real benefits to test-after. The risks of writing a test that mirror an implementation are higher. The risk of undertesting is higher.

And, I've also noticed that people who are very thorough with test-after tend to over test.

Why we dont like TDD

Related Stories