[DRMacIver]

> Hypothesis is a quickcheck port to python

If you'll pardon the pedantry (I think the distinction matters, honest), Hypothesis isn't really a QuickCheck port. It started out life that way, and it can be used in a way that that is pretty compatible with QuickCheck, but implementation-wise it's very different and it has a bunch of interesting non-QuickCheck features.

I totally agree that this is great news though, and I'm very grateful to Stripe. :-)

[hprotagonist]

Authors of a thing are _always_ allowed to be pedantic about that thing, in my book.

thanks for your hard work, you saved me a lot of my own.

[bennofs]

> very different and it has a bunch of interesting non-QuickCheck features.

I'm only familar with QuickCheck, but what are those differences / features? Couldn't tell from a quick look at the website of Hypothesis.

[DRMacIver]

Internally, Hypothesis is built on a core engine called Conjecture, which looks more like a byte stream fuzzer than anything else. Hypothesis data generators are then effectively parser combinators on top of that fuzzer.

This gives Hypothesis a lot more freedom to generically manipulate the data than QuickCheck has, because it has total control of a concrete representation of it.

As a result:

* Specifying a data generator is a much more declarative process - Hypothesis largely handles size/distribution issues itself.

* The fuzzing nature of Hypothesis means that it can do much smarter generation than a normal QuickCheck (though this is more potential than actual right now. The current fuzzer is "pretty good". I'll be starting a PhD soon where I hope to work on making it amazing)

* Shrinking is just a built in part of the process and users never have to define their own shrinker.

* All examples (both pre and post shrinking) can be serialized because the IR is just bytes, so Hypothesis can replay failing tests automatically without rerunning the shrinking process. This matters both because shrinking tends to be slower than generation in most QuickChecks, but also because in general shrinking is subject to "slippage" where the bugs you find after shrinking are different from the bugs you started with.

* Because you can just keep drawing data from the stream, Hypothesis tests can be much more interactive than normal QuickCheck (which does support mixing test execution and generation, but it doesn't work especially well).

* Because Hypothesis never needs to touch the values it generates, Hypothesis is much better for mutable data than the approach most QuickCheck takes.

* I haven't actually done this yet, but Conjecture is deliberately designed to be quite C like, so "at some point" it will become possible to rewrite the core in C (more likely Rust) and then new Hypotheses will spring up everywhere because 90% of the work can be done by writing bindings to a C library. QuickCheck's approach on the other hand is inherently very tied to the semantics of the host language.

The property-based testing libraries for some dynamic languages (test.check for Clojure, the various Erlang ones including QuickCheck) have some of these features, but I think they're more naturally supported in the Hypothesis model, and the Hypothesis model has a lot more room to grow.