RamFuzz

As I explain in the RamFuzz overview paper [0], Dan Luu's idea is unlikely to work because fuzzing uses mutation techniques developed for file input, not individual parameter values. What does seem to work is frameworks like EvoSuite and eToc, which mutate method-invocation sequences to try and maximize coverage. And yes, QuickCheck (or RapidCheck[1], for C++) is what you need if you enjoy manually specifying your test inputs. RamFuzz is a tool to support research into automating that and, eventually, the entire process of writing unit tests. [0] https://github.com/dekimir/RamFuzz/blob/master/sci/ramfuzz.m... [1] https://github.com/emil-e/rapidcheck

I looked into this while making RamFuzz[1], but parameter generation (QuickCheck) is quite different from input-blob evolution (AFL). It wasn't clear to me how best to leverage a parameter mutation that happens to increase coverage. Ultimately, I decided that random generation (without guidance by coverage) coupled with AI classification of test outcomes is the most interesting approach. [1] https://github.com/dekimir/RamFuzz

I like Beck's vision for the future, and I agree that we should keep experimenting in order to learn which tests tend to work and why. But we don't need to do it all manually -- we can use computers to automate and speed up such experiments. To that end, I've started a project to automatically generate unit tests from C++ source: https://github.com/dekimir/RamFuzz Right now the generated tests are pretty superficial and silly, but the key is that they are randomized. Because of this, we can run millions of variations, some of which will prove to be good tests. Right now I'm hacking an AI that will pick those good instances from many random test runs. If it works, we'll be able to simply take source code and produce (after burning enough CPU cycles) good unit tests for it. This will be a huge help in letting the human programmer only