5 ms·
Even if you're writing fully managed code you should still fuzz. It can help find logic errors in the code which can cause erroneous program states or crashes.
by cornstalks 11y ago
Even if you're writing fully managed code you should still fuzz. It can help find logic errors in the code which can cause erroneous program states or crashes.
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.
- wyldfire 11y agoAgreed! 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."
- andrewchambers 11y agoAnd then after that you need to go into formal proofs.
- mraison 11y agoThere 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 https://github.com/clojure/test.check
- viraptor 11y agoSure, 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.