Comment by bob1029
5 hours ago
> if you take that approach when testing all the thousands of components together, which is simply just too complex to exhaustively model[1], you'll never get anywhere.
This is exactly why ideas like test-driven development don't work well as a general approach.
Most realistic systems exhibit non-linear interactions where correctness is not compositional. Local correctness does not compose upward in any meaningful sense. Top-down design (working backward from the customer) allows for you to perform what is effectively one big global search. Bottom-up design (TDD) requires many local searches that all have to fit together perfectly at the very end. With units & composition, the consequences of component A's interactions with component B may not be considered until nearly the end of the project. If you are testing an integrated vertical, you will discover these interactions much earlier.
That's not how TDD works. You test the whole chain and all the components with tests and you can move from top to bottom with TDD, it's actually how you should do it.
There's a disconnect between TDD using all sorts of tests (unit, integration, hardware-in-the-loop, in-field, etc.) and TDD using unit tests only. Unit tests provide the least value/line of test code of all types of tests. They're important, since they can catch bugs earlier than other sorts of tests that can't be caught by a type system, but not sufficient to catch most bugs.
It is however how most software testing is done.
"Most" is a gross exaggeration.