This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-08-02
Channels
- # admin-announcements (3)
- # architecture (5)
- # beginners (10)
- # boot (223)
- # cider (13)
- # cljsjs (2)
- # cljsrn (50)
- # clojure (208)
- # clojure-austin (16)
- # clojure-belgium (1)
- # clojure-india (1)
- # clojure-poland (13)
- # clojure-russia (130)
- # clojure-spec (27)
- # clojure-uk (144)
- # clojurescript (135)
- # css (2)
- # cursive (10)
- # datavis (1)
- # datomic (29)
- # dirac (9)
- # funcool (2)
- # hoplon (41)
- # jobs (3)
- # leiningen (6)
- # om (37)
- # onyx (20)
- # pedestal (1)
- # planck (1)
- # proton (4)
- # re-frame (45)
- # reagent (17)
- # rethinkdb (16)
- # ring-swagger (19)
- # schema (5)
- # specter (93)
- # sql (16)
- # test-check (33)
- # untangled (7)
is there a good resource to help understand shrinking; how it works, what to consider etc...
it seems like quite an involved topic
I’m interested in this. I have a reasonable intuition about it, but I’d like something in more detail
well I can answer specific questions about it at least
for the most part the shrinking strategy mirrors the structure of your generator
e.g., tuple shrinks by shrinking its elements; collections shrink by deleting elements and shrinking elements
fmap shrinks by shrinking the underlying element and running it through the function again
bind is a little weird though, and therefore so is gen/let
@alexmiller: regarding the test.check issue described in CLJ-1997, I'm considering pasting all the relevant code from riddley into test.check as the most practical option. I'm wondering if you see any problems with doing something like that for a contrib library.
I've started moving away from generators like gen/frequency
that don't shrink in favor of those that provide predictable shrinking behavior such as gen/one-of
the idea being that when there are multiple possible values that require different generators, it will shrink along an axis of my choosing
for example, I have a node on the tree structure I generate where most of the time the value is an element from a collection, but sometimes it's not – however for most of the problems I encounter, that doesn't matter
it will definitely test the case where there's a thing, but will shrink towards there not being a thing
in some cases where things
is a fixed size, I actually use gen/one-of
to force a shrinking preference, since gen/elements
is always random; you'd have to shrink the size of the input if you wanted predictability
(and feel free to correct me if I'm wrong – I'm going off of observation from usage and cursory readings of the code)
@mattly: what makes you say gen/frequency
doesn't shrink?
oh I see; I'm inclined to say that's a bug
@gfredericks: my experience of using it, that example before, the frequencies didn't seem to matter when shrinking
I would think it should shrink toward earlier generators like one-of
does
so f.e. [[3 (gen/return nil)] [1 (gen/elements things)]]
it'll still pick gen/elements
would you like to file the bug or shall I?
I'm planning to do a writeup on my usage of test.check and property-based testing on the system I'm working on
there's a lot of material out there on what it is, but very little on how to use it effectively