proptest VS quickcheck

In this post, I will tell you how I used property testing with the Proptest library in Rust to ensure the correctness of a bunch of generated serialization/deserialization code for the Apache Kafka protocol.

proptest: Property-based testing with random input generation.

Isn't proptest something that could handle this?

https://github.com/proptest-rs/proptest

Proptest is a Rust crate for property-based testing. Recently I wanted/needed to manually implement a proptest strategy for my own type, and I realized that there is not that much material on how to do it. So I wrote a post where I tried to describe what I learned. It's a bit niche, but I hope that someone at some point will find it useful.

Take a look at proptest.

Yes exactly, you can also add to this fuzzing and property based testing.

proptest is great! It generates random input data according to some rules, and if the input fails it saves random seed into a file so that failing inputs are guaranteed to be tested on the subsequent runs (as well as new random inputs). It also doesn't immediately stop on fail but tries to find a minimal failing input first.

The only other crate I could find is proptest, but it looks a lot more complicated, and I don't know if lets you skip the shrinking step as quickcheck does. I've been reading the book and going through the docs, but a quick answer would be appreciated.

We just released proptest 1.1.0, a property-testing framework for Rust. Proptest has recently found new maintainers, and this marks the first new release of proptest in ~2 years.

Hi, I'm working on a fuzzer, that fuzzes APIs based on OpenAPI specification. I'd like to implement shrinking. It means that when an interesting input (for the API) is found, I'd like to create the smallest possible input that still causes the same behaviour of the API. I'd like to implement a payload generation via proptest, because it already has the shrinking ability. I'm having issues implementing the JSON object as a proptest strategy. Here is what I tried so far. I explained it in a detail in stackoverflow question but it did not reach many people. Thanks for your help!

Which means: if the caller guarantees that the parameter ptr is not null, then result.as_ptr() is the same as the passed ptr

That's a kind of trivial contract but Kani tests for all possible pointers (rather than some cherry picked pointers like the null pointer and something else), without actually brute-forcing them but instead recognizing when many inputs test the same thing (while still catching a bug if the code changes to handle some input differently). And this approach scales for non-trivial properties too, a lot of things in the stdlib have non-trivial invariants.

You can check out other proofs here https://github.com/search?q=repo%3Amodel-checking%2Fverify-r...

It's not that different from writing a regular test, it's just more powerful. And you can even use this #[requires] and #[ensures] syntax to test properties in regular tests if you use the https://crates.io/crates/contracts crate.

Really if you have ever used the https://proptest-rs.github.io/proptest/intro.html or the https://crates.io/crates/quickcheck crate, software verification is like writing a property test, but rather than testing N examples generated at random, it tests all possible examples at once. And it works when the space of possible examples is infinite or prohibitively large, too.

Maybe https://github.com/BurntSushi/quickcheck too?

Yeah as other have mentioned, I was using Rust before 1.0.

This is my first public commit: https://github.com/BurntSushi/quickcheck/commit/c9eb2884d6a6...

I didn't write any substantive Rust before that point. So I'm at over 9 years.

The book, Zero To Production In Rust, uses quickcheck:

Hi all! I'm looking for some feedback on my latest crate, reltester. It's a small utility crate that, when paired with property-based testing with e.g. quickcheck makes it very easy to check that your handwritten comparison trait implementations satisfy the necessary constraints (transitivity, reflexivity, and all that stuff). I wrote it our of frustration after finding many subtle bugs in our PartialEq and PartialOrd implementations at $JOB, and hopefully someone else will find it useful.

For what it's worth this would also be a good candidate for property based testing, like with: https://github.com/BurntSushi/quickcheck

I'm aware of Hypothesis and its approach, but the connection between Hypothesis and arbitrary is indeed non-obvious. Even looking over the API docs again, the most I could pick up was this on the docs of Unstructured:

Quickcheck https://github.com/BurntSushi/quickcheck