{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreicdgkljhckovyo6skgkfmp6g3bhwk5d6y4t2xzaxjnvosak3sgmiq",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3mieyigejl5s2"
  },
  "path": "/t/why-not-use-smallcheck/13860#post_9",
  "publishedAt": "2026-03-31T18:19:43.000Z",
  "site": "https://discourse.haskell.org",
  "tags": [
    "extensive test suites"
  ],
  "textContent": "turion:\n\n> If it’s important to have spaces and newlines, then you can simply merge a generator that produces them into the default one.\n\nHow would you know upfront whether it’s important or not? If I definitely know that something is important, I’ll write a unit test to nail it down, no need for quickcheck or smallcheck. The very point of property testing is to get confronted by unknown. And QuickCheck will just throw at me spaces, newlines, digits, punctuation, upper case, lower case, Unicode and what not. While SmallCheck will require me writing a dozen of newtypes with different generators and tweak depth here and there. And all of it for what?\n\nI mean, one can definitely make SmallCheck work. I have fairly extensive test suites using SmallCheck. Guess what? I’ve never seen a case where it would spot a bug, which QuickCheck didn’t.\n\nAmbrose:\n\n> strings don’t see like a reason to deprecate smallcheck in favor of QC tho lolol. A reason to use QC, yeah. But using sc with strings is just using it wrong..\n\nWhat would be a reason to use SmallCheck _tho lolol_?",
  "title": "Why not use smallcheck?"
}