> so nobody ever does outside of QA who does end-to-end black box testing and just kind of hopes they've covered all of their bases (hint: they didn't).
You don't need to cover all bases, in 99% of software. (And in the 1% where you do, you should probably be using formal verification.)
Testing is an investment and should be analyzed in terms of ROI. There is a cost to writing tests in advance, a cost to fixing bugs after writing the code, and a cost to shipping software with bugs left unfixed on rare codepaths. Sometimes TDD yields high returns indeed (usually for "library code" that (a) does something very complicated on a complex data structure; (b) is easily isolated from the rest of the system without writing tons of mocking infrastructure; (c) has a stable API that is not frequently refactored.) Often it does not. I've found that a combination of static assertions, black-box systems testing, and incrementally adding regression tests during debugging allows me to develop good code more efficiently than TDD the vast majority of the time. Your mileage may vary, of course.
You don't need to cover all bases, in 99% of software. (And in the 1% where you do, you should probably be using formal verification.)
Testing is an investment and should be analyzed in terms of ROI. There is a cost to writing tests in advance, a cost to fixing bugs after writing the code, and a cost to shipping software with bugs left unfixed on rare codepaths. Sometimes TDD yields high returns indeed (usually for "library code" that (a) does something very complicated on a complex data structure; (b) is easily isolated from the rest of the system without writing tons of mocking infrastructure; (c) has a stable API that is not frequently refactored.) Often it does not. I've found that a combination of static assertions, black-box systems testing, and incrementally adding regression tests during debugging allows me to develop good code more efficiently than TDD the vast majority of the time. Your mileage may vary, of course.