Our great sponsors
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
> and also to automatically shrink any counterexamples it finds to be as simple as possible.
This actually is a problém with most quickcheck clones (and quickcheck itself), that's why it's better to use a library that is inspired by Python's Hypothesis (combining generation and shrinking, in a nutshell). So Hedgehog for Haskell and F# (instead of Fscheck) and Rapid for Go https://github.com/flyingmutant/rapid
But tables and property tests complement each other, even if you can get rid of some tables by using property testing.
Example article about the shrinking of Hypothesis vs. Quickcheck
I'm fond of taking this a step further and actually offloading the test cases to a separate language-agnostic file, then have implementations' test harnesses read cases from that file. The Ruby gem for Base32H¹ does exactly this to test the encoder/decoder logic, pulling the test cases from CSV files in a separate repo² included as a Git submodule. One of these days I need to port the other reference implementations over to using the tests repo, but once that's done I'll be able to update the test cases in one place and they'll automatically work everywhere.
----
¹ https://github.com/Base32H/base32h.rb/tree/master/spec
² https://github.com/Base32H/base32h-tests
I'm fond of taking this a step further and actually offloading the test cases to a separate language-agnostic file, then have implementations' test harnesses read cases from that file. The Ruby gem for Base32H¹ does exactly this to test the encoder/decoder logic, pulling the test cases from CSV files in a separate repo² included as a Git submodule. One of these days I need to port the other reference implementations over to using the tests repo, but once that's done I'll be able to update the test cases in one place and they'll automatically work everywhere.
----
¹ https://github.com/Base32H/base32h.rb/tree/master/spec
² https://github.com/Base32H/base32h-tests
There's some efforts to guide test generation for property based testing to make the instruction pointer explore as large a space as possible.
This effort is more mature in the fuzzing community. See eg American Fuzzy Lop https://github.com/google/AFL
Table driven tests are a lot better than a bunch of imperative tests but they rapidly become unwieldy to debug, maintain, and evolve. Their readability often isn’t great.
If you’re using go, check out https://github.com/cockroachdb/datadriven. It takes a little bit of effort to craft a testing dsl, but it is so worth it.
Also, snapshot style testing where the test writes out its expectations and you just inspect it and save it (part of datadriven) is wonderful.
I’ve been using insta in rust lately and it’s some of what I want but not quite datadriven.