How does this compare to proptest?

Hello. I just stumbled upon this library. It looks really nice 👍

I’ve been using property-based testing with great success to find bugs in an immutable list implemented in TypeScript. It’s really good to see a great looking TS implementation of property-based testing. The library I’ve been using is proptest. Would you happen to know how this library compares to Proptest?

One thing I really like about Proptest is the following (from the readme):

Shrinking is done by generating lazy rose trees of values directly. This means that you can map and chain generators and get correct shrinking functions “for free”.

That is, the generators (which is what fast-check calls arbitraries) in Proptest are monads. It is possible to map them, chain them, and more. As far as I can see fast-check has a map function for its arbitraries but no monadic bind?

Additionally, Proptest has a nice integration with testing frameworks. See the example here. It makes it possible to declare tests in a really concise way. Have you considered adding something similar to fast-check?

Having to write fc.assert(fc.property(...)) seems a bit cumbersome. Have you considered adding a function that is the composition of the two?

[dubzzz]

@paldepind

chain

I just had a look into proptest (looked at the code and played with it). It indeed comes with a built-in chain method.

Unfortunately, it has the same problem as the one I decribed above concerning the poor shrinking of such chaining. In the case of this precise framework, a chained value is only shrunk on the last dimension - the chain of fast-check shrinks on both dimensions.

Moreover, this chain method is used to build .array() in proptest, so the impact of the poor shrinking is easily visible.

If you have a look into https://runkit.com/dubzzz/5b1bc7a8fd2901001208d045 You’ll see that for the property:

an array of natural numbers never contains a 8 (obviously false)

Counterexample for proptest: [8, 0, 0, 0, 0, 0, 0] Counterexample for fast-check: [8]

other remarks

I think that the output of proptest could have been more verbose. For instance, it does not specify the seed that was used.

It also fails to generate large values by its own (certainly needs a manual intervention):

// this one was always true in my case
property(
  'all natural numbers are inferior to 1000',
  QC.nat,
  x => x < 1000);

[dubzzz]

@paldepind You might be interested: I started working on your idea to merge assert, property and it all together. The current proposal is described in #109.