Why we dont like TDD(oneuptime.com)
oneuptime.com
Why we dont like TDD
https://oneuptime.com/blog/post/2023-11-21-why-we-dont-like-tdd/view
6 comments
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"
> 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.
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.
Interesting idea but what exactly is a dev test for you? And when does it qualify as a ci test?
For me, dev testing is something that I use directly in the hot feedback loop of writing code. Typically, I'll run it after every change then manually inspect the output for quality assurance. it could be as simple as refreshing the browser or re-running a CLI tool and spot checking the output. Importantly, dev tests for me are not fully fleshed out - there are gaps in both the input and output specifications that preclude full automation (yet), which means my judgement is still in the loop.
No so with CI tests. Input and output are 100% specified and no manual intervention is even possible.
There are some problems where "correct" can never be well defined. Think of any feature that has aesthetic values implied. You can't just unit test the code, brush off your hands and toss garbage over the wall for QA or your customers to pick up!
I use this technique mainly to avoid an over-reliance on automated testing. I've seen far too many painful situations where the unit tests pass but the core functionality is utterly broken. It's like people don't even bother to run the damn program they're writing! Unacceptable and embarrassing - if encouraging ad-hoc tests and QA-up-front helps solve this, it's a huge win IMO.
No so with CI tests. Input and output are 100% specified and no manual intervention is even possible.
There are some problems where "correct" can never be well defined. Think of any feature that has aesthetic values implied. You can't just unit test the code, brush off your hands and toss garbage over the wall for QA or your customers to pick up!
I use this technique mainly to avoid an over-reliance on automated testing. I've seen far too many painful situations where the unit tests pass but the core functionality is utterly broken. It's like people don't even bother to run the damn program they're writing! Unacceptable and embarrassing - if encouraging ad-hoc tests and QA-up-front helps solve this, it's a huge win IMO.
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.
>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.
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.