[antonovka2]

No amount of testing the former will lead you to realize the latter. Sure, you might happen to come to the realization while writing the test, but you might do so over breakfast too.

You're a bit more likely to do it during a time you've set aside to fully consider potential failure scenarios.

[ajross]

I guess I can't argue with that, as it's essentially unfalsifiable. But it's worth pointing out that writing a unit test, which is the subject that started this discussion, is definitely not a time when you're "fully considering potential failure scenarios". Unit tests are narrow and focused, and aimed at verifying features.

What you're talking about is something I'd call white box QA. Which is valuable, though it's essentially just an extension of design, and has the same limits.

My broad point still stands: you can't "process" your way out of this with extra testing. Some bugs are just inherent, and stem from the fact that we're human.

[antonovka2]

Unit tests are narrow and focused, and aimed at verifying features. What you're talking about is something I'd call white box QA. Which is valuable, though it's essentially just an extension of design, and has the same limits.

It seems like most negative arguments regarding "unit tests" start by defining them as a small subset of what can be usefully tested, and then arguing against the value of testing such an incomplete subset.

I don't see the point of drawing such an arbitrary line. I leverage "unit" tests to automatically test units of code as completely as possible (not just 'verify features'), and I expect the same of tests that others write.