How is the A stuff wrong when thousands of people have used it successfully(presumably for its intended purpose) thousands of times? I understand where you're coming from. But the longer I do this, the less dogmatic about testing I get. If the code works for its intended purpose then it's probably all right. Now, adding features and having confidence in refactoring is another story with untested code.
I recently discovered something interesting. The requirements gathering we do kinda sucks. How often do we bring in end users and watch them use the system as they do? Why do we not trust user input with our code but do with our ears? I recently got the opportunity to do this for a project that's being rewritten. The information you gather from this is gold.
The reason thousands of people have used it successfully is because most people are not developers, aren't lazy and willingly accept having to do something inefficiently over and over again. If there is some flaw in the way the system works then people will adapt and go around the mountain. They won't even think about this and, if it's so automatic that it's buried in their unconscious, they may never even think to tell you.
The other reason people have used it successfully is because they assumed that the broken output was correct. If it's not tested, how do you know that your report generator is spitting out the correct figures?
Also, kind of related, just as one of the benefits of unit testing is that you write well structured and testable code, one of the benefits of functional testing is that you think about the interface. I'd consider any inefficient interface to be a bug.
Do you write lots of security fuzz unit tests? Cause I don't. I write tests that hit the edge cases I can think of, but invariably, I can't think of everything. I really don't think the security argument has much to do with unit testing.
