4 ms·
It keeps coming back to the same stupid erosion of paradigms. Once upon a time, some developers that were smarter than others started testing their code. They
by potherca 2y ago
It keeps coming back to the same stupid erosion of paradigms.
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
- naasking 2y agoStudies 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.
- potherca 2y agoYeah, 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.
- eesmith 2y agoI'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.
- naasking 2y agoI 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.
- eesmith 2y agoYes, 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.
- potherca 2y agoTrue 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.