[jawns]

I started learning about this type of testing by writing Hypothesis tests for Python code: https://hypothesis.readthedocs.io/en/latest/

One of the things that became a source of frustration is writing the specs that define the shape of the inputs.

Does FuzzBuzz make that any easier?

[evmunro]

That's a problem that we've been thinking about a lot. The way our fuzzing works right now is that your method consumes an array of bytes, which you can then use to build up arbitrary structures. It's simple, but manages to be really generic and flexible at the same time. Of course, it means you do have to define what your inputs look like.

We do have plans to build some tools to make this easier. I'd like to see a scenario where defining inputs is as simple as specifying the data types that your code requires. (Or perhaps even automatic detection, for less complex cases)

[guidovranken]

Some people use Protobufs to solve this, but when I work with C++, I use a class that takes a (data, size) as an input (to its constructor), and implements an overridable Get<T> method.

So you can do: auto s = datasource.Get<std::string>();

For each type I need I override Get<T> for that type. If the data source class is out of data, I throw a specific exception, that I catch at the global level. This works like a breeze and the advantage over protobufs is that it's faster (no Protobuf parsing overhead, errors) and you never consume more than you need.