Comment by MoreQARespect
9 days ago
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.
Often, even outside of software, unit testing means testing a component's (unit‘s) external behavior.
If you don't accept that concept I can see how TDD and testing in general would be challenging.
I general it is most productive when building competency with a new subject to accept the author's definitions, then adjust once you have experience.
IMHO, the sizing of components is context, language, and team dependent. But it really doesn't matter TDD is just as much about helping with other problems like action bias, and is only one part of a comprehensive testing strategy.
While how you choose to define a 'unit' will impact outcomes, TDD it self isn't dependent on a firm definition.
1 reply →