I have used hypothesis some and quite enjoyed it. It isn’t quite as nice as QuickCheck or JSVerify (my go-to for QC-style testing in JS), but still quite good.
My big complaint was (as of ~0.4…which was released in late January) that it was more difficult to define new compound types than I was used to. I used JSVerify to generate random geometric data to test methods to recover information from a lossy transform (specifically: the mapping from 3-space to 2-space). It worked quite well and I was happy with how easy it was to define and compose complex types. This might have changed since hypothesis 0.4
I have used hypothesis some and quite enjoyed it. It isn’t quite as nice as QuickCheck or JSVerify (my go-to for QC-style testing in JS), but still quite good.
I’m always up for trying to improve it. I’d be interested to hear any other problems you had, although 0.4 was long enough ago and enough has improved since then that I expect/hope a lot of them have been fixed (the current release is 1.3, and there were some really major changes around the 0.7 release).
For the specific case of compound types: It really depends a lot on what you mean by “compound types”, but the short answer is that I would be extremely surprised if this was still something you had a problem with.
Hypothesis strategies are automatically derived for tuples and similar, and you can map (and flatmap) over Hypothesis types so any compound type which you can build out from types that Hypothesis can already generate can be defined in a line or two, and you get the full set of features - simplification, serialization, etc. for free.
For strategies where you really want to define a custom generator you can use the BasicStrategy interface.
If you really really want to use the full Hypothesis SearchStrategy interface it’s not too bad. It is more involved than for Quickcheck, but that’s because Hypothesis is a lot more powerful than standard QuickCheck. Here’s a worked example of an implementation from scratch.
I have used hypothesis some and quite enjoyed it. It isn’t quite as nice as QuickCheck or JSVerify (my go-to for QC-style testing in JS), but still quite good.
My big complaint was (as of ~0.4…which was released in late January) that it was more difficult to define new compound types than I was used to. I used JSVerify to generate random geometric data to test methods to recover information from a lossy transform (specifically: the mapping from 3-space to 2-space). It worked quite well and I was happy with how easy it was to define and compose complex types. This might have changed since hypothesis 0.4
I’m always up for trying to improve it. I’d be interested to hear any other problems you had, although 0.4 was long enough ago and enough has improved since then that I expect/hope a lot of them have been fixed (the current release is 1.3, and there were some really major changes around the 0.7 release).
For the specific case of compound types: It really depends a lot on what you mean by “compound types”, but the short answer is that I would be extremely surprised if this was still something you had a problem with.
Hypothesis strategies are automatically derived for tuples and similar, and you can map (and flatmap) over Hypothesis types so any compound type which you can build out from types that Hypothesis can already generate can be defined in a line or two, and you get the full set of features - simplification, serialization, etc. for free.
For strategies where you really want to define a custom generator you can use the BasicStrategy interface.
If you really really want to use the full Hypothesis SearchStrategy interface it’s not too bad. It is more involved than for Quickcheck, but that’s because Hypothesis is a lot more powerful than standard QuickCheck. Here’s a worked example of an implementation from scratch.
Wonderful! I’ll take another shot at it soon and if it still is lacking I’ll submit an issue or PR (depending on my free time).