{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreihmk6ko3arkbmwzxqsik77jblsukh27bby7ibz2b4o7olaxibbhc4",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3mid3pm7vx5n2"
  },
  "path": "/t/why-not-use-smallcheck/13860#post_6",
  "publishedAt": "2026-03-30T22:38:22.000Z",
  "site": "https://discourse.haskell.org",
  "tags": [
    "@turion"
  ],
  "textContent": "@turion the problem is not the raw performance of inputs generation, the problem is that for a given depth their number grows exponentially. So with default depth 5 a record with 6 fields will generate roughly 5^6 test cases. And if your property takes two of such records, it’s 5^12, almost a quarter of a billion of them. So at this point you start to micromanage `smallcheck` tweaking depth here and there (which is already annoying) and end up setting depth of 2 for such test. It’s still at least 2^12 test cases, which is probably okayish, but you are barely testing anything with such depth, right?..\n\nImagine testing a property on strings. What would you like `smallcheck` to do? Should it limit itself to enumerating `['a'..]` for small depth? In such case it would never generate even something very simple, like a string with a space. Or a digit. Or an upper case letter. `quickcheck` is so much better: in a matter of microseconds it will throw all kinds of inputs on your test property.",
  "title": "Why not use smallcheck?"
}