Comment by nyrikki
9 days ago
The problem with TDD is that people assumed it was writing a specification, or directly tried to map it directly to post-hoc testing and metrics.
TDD at its core is defining expected inputs and mapping those to expected outputs at the unit of work level, e.g. function, class etc.
While UAT and domain informed what those inputs=outputs are, avoiding trying to write a broader spec that that is what many people struggle with when learning TDD.
Avoiding writing behavior or acceptance tests, and focusing on the unit of implementation tests is the whole point.
But it is challenging for many to get that to click. It should help you find ambiguous requirements, not develop a spec.
I literally do the diametric opposite of you and it works extremely well.
Im weirded out by your comment. Writing tests that couple to low level implementation details was something I thought most people did accidentally before giving up on TDD, not intentionally.
It isn't coupling low level implementation details, it is writing tests based on input and output of the unit under test.
The expected output from a unit, given an input is not an implementation detail, unless you have some very different definition of implementation detail than I.
Testing the unit under test produces the expected outputs from a set of inputs implies nothing about implementation details at all. It is also a concept older than dirt:
https://www.researchgate.net/publication/221329933_Iterative...
If the "unit under test" is low level then thats coupling low level implementation details to the test.
If you're vague about what constitutes a "unit" that means youre probably not thinking about this problem.
2 replies →