4 ms·

I like the double-entry bookkeeping analogy, but isn't it true for all tests? In fact, as the article explains, in the old days it was a specialized QA departme

by js8 5y ago

I like the double-entry bookkeeping analogy, but isn't it true for all tests? In fact, as the article explains, in the old days it was a specialized QA department (different from development) which wrote tests often just based on specs, and the barrier (also called black-box testing) was there precisely to have independent verification. It seems to me that this argument favors the old methods and not TDD in particular.

groby_b 5y ago
The key is the automation of the tests. I personally hold the belief that the logic author should also be the spec author, and it's QA's jobs to find gaps in your model of the world. The barrier means QA doesn't have the same model, and often lacks info that you have. That's valuable in some aspects, but it's not double-entry. (Double entry in accounting means that you always record two transactions that need to match each other, not that there's independent verification - that'd be auditing) I believe you need both double-entry and independent verification. (Of course, that depends on scope & desired quality. Your 100-line bash script that you only run to print fortunes for your friends probably needs less rigor than products that are used by billions, or that have life-or-death impact) You're right that it's not specifically TDD that enables this - but you do want automated unit tests written by the developer, whatever methodology you use. (Or at least I want them :)