Studies on TDD has failed to show a benefit over writing tests after the fact. The only factor that seems to matter is writing tests, the more tests the better. If you can write your code so it's amenable to more testing, or such that it requires fewer tests because it's simpler/has fewer cases to handle, great. If you have a framework that can generate tests (fuzzing, property-based testing), awesome.
Re:Unit Tests Considered Harmful
by marcosdumay on Friday April 12, 2024 @09:56AM
(#40012940)
Studies on software engineering are all low reliability ones full of confusing factors.
(What's the matter with SE as a discipline?)
Yeah, that's something I've been promoting for years. I don't care whether you write tests first or last, as long as you eventually get into a feedback loop of coding and verifying your code, quality will improve.
The same goes for customer specs. Just build a thing and verify if this is right.
Rinse, repeat. Progress is the only metric.
I'm pretty convinced that test-first is best seen as a negotiating technique to get the time to write the tests in the first place.
"Okay, the code is done, time to write the tests" results in pressure to shorten testing, since if the golden path works then surely everything else works, right?
Your management and your sales people then say "You're a great developer, it looks like it works, and we need to deploy that code now because customers are demanding it and the competition is breathing down our necks."
It's hard to resist that pressure.
While saying that it's best practices to do TDD means you don't need to deal with that sort of negotiation.
I can see that, but only because the dev has arguably already made the mistake of showing sales working features before tests are written. I've always been clear to say when something is a partial mockup to verify that I've understood what they're asking for.
Yes, but many places don't have a healthy work environment, and developers are generally younger, less confrontational, and less experienced at negotiating than management and sales.
True that. One of the major factors of my success as a software developer is a lack of fear (either through stupidity or bravery) of "taking on" toxic/unfair/destructive environments and people.
Once upon a time, some developers that were smarter than others started testing their code. They described ways to test smaller parts of large software systems separately before being integrated together.
For instance "parameter testing" (to validate component subprograms against their specification) and "assembly testing" (for parts put together)[^1]
As always happens, a formal definition soon followed and the industry settled on names like "unit tests", "component tests" and "integration tests".[^2]
Of course, as soon as things are describes somewhere, this means there is documentation for developer to ignore. Or misinterpret.
Next thing you know, "Unit-Testing" is (ab)used, and people start complaining it doesn't work.
So some developers that were smarter than others say "You are doing it wrong!" and describe a better way of doing things... For instance, writing the test _before_ you write the code, so the scale/scope of a "unit" is defined beforehand. There is much rejoicing, and TDD is the new magic bullet.
So now there is more documentation for developer to ignore. So some developers that were smarter than others say "You are doing it wrong!" and define BDD, which is basically just TDD "done right", as the term TDD has become polluted. [^4]
So now there is more documentation for developer to ignore. So some developers that were smarter than others say "You are doing it wrong!" and define DDD, which is basically just BDD "done right", as the term BDD has become polluted.
And so the merry dance continues.
Rather than understanding which practice helps improve quality in which (coding) problem domain, developers stomp around with their preferred hammer, looking for nails, complaining about everybody else's hammer.
I'd say, rather than using one or the other, based on developer desired, focus on things from the user perspective... Take a look at the Test Automation Pyramid and start writing the right tests in the right domains depending on business/domain value.
[^1]: H.D. Benington, 1956 [^2]: James J. Donegan; Calvin Packard; Paul Pashby, 1964 and Norman A. Zimmerman, 1969 [^3]: Lee Copeland, 2001 [^4]: Dan North 2006