Agreed! I like to think of the fuzzers as merely an automated tool to drive test cases, maximizing on coverage.
So when asked, "Why fuzz test?" I can answer, "remember when you wrote fifteen test cases and wondered to yourself whether you needed a sixteenth? But then you decided that it would take more work than it's worth to do that. -- Well, now we can tell the computer to just keep trying stuff until it finds unique cases."
There is also generative testing, which can be a good middle-ground between hand-crafted tests and fuzzing. You can think of it as a fuzzer with more guidance regarding input generation, and can uncover edge-cases that a fuzzer would take forever to discover. I tend to think of those 3 approaches as complementary.
Example in Clojure: https://github.com/clojure/test.check
Re:Fuzzing FFmpeg for fun and profit
by andrewchambers on Sunday November 01, 2015 @11:46PM
(#10490035)
And then after that you need to go into formal proofs.
Sure, I mean fuzzing should be critical for applications which can sigsegv, but it doesn't mean others shouldn't also give it a go. It just requires some integration support (you need to let the fuzzer know that an exception got all the way to the top for example), so it's up to the project if they want to go that way.
The fact that the code is managed helps prevent against some nasty exploits, but it doesn't necessarily mean the code always does what the programmer intended.