2 ms·

> TDD/FP/Agile zealots So his phrasing is a little hard to follow here, but I take this as being part of the ongoing TDD backlash, which is unfortunate because

> TDD/FP/Agile zealots So his phrasing is a little hard to follow here, but I take this as being part of the ongoing TDD backlash, which is unfortunate because in my 30 years of experience, the opposite of TDD is "not testing anything at all". Or rather, when somebody pushes back against TDD, they usually push back against any form of unit testing. The net result is that the code itself is difficult to impossible to actually test... 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). I guess I'd have to understand better what his definition of a TDD "zealot" is because I've been accused of being one for insisting that non-trivial code that doesn't have unit tests (and doesn't even allow for them) is unacceptable.

evouga 5y ago
> 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.

evouga 5y ago

> 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.