Yes, Reductio will generate implementations of an interface (or a class), however, there is often a small amount of work to do on your behalf. You might even consider this work to be “boiler-plate” since it is so systematic and requires no thinking. Ultimately, you will require an Arbitrary<T> where T is your interface or class.

Classes can be shown to be convertible to/from zero or more transformations and since Reductio can construct arbitrary transformations (see reductio.Arbitrary.arbF), then it is simply a matter of converting them to the appropriate class, type using the overloaded Gen.bind method, which allows up to 8 transformations, however, if more are required, then they can be written using the Gen.apply method. That is to say the overload of Gen.bind that accepts N transformations can be written quite easily using the Gen.bind for N-1 transformations plus apply. I understand that this might sound complicated, but it’s really easy to do; perhaps a future tutorial
PS: Thanks to the others who corrected my mistake.

addThenSubtract(a, -a)

Plus, really, your unit tests should be testing for different return values, it’s pretty pointless if you do 100 tests for the same return value.

I agree though, testing is important and automating testing is important. There should also be separation of unit tests like these and actual blackbox testing that is also automated. Yes, I think developers should do their own blackbox testing during a build cycle(hopefully continuous)

To make things concrete: how could I verify that a certain row has been inserted in the database after I update an object?

…

For example, when x and y are the same value, you will always get back -7.”

Are you sure?

Automated tests are interesting, but they are just code. Sometimes bad code.

Also, I think you could pick an example that is easier to identify with for programmers, though I personally found a + b - b == a quite good fun with students (especially where a is a float).