# test-check

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

rickmoynihan 15:59:02

is there a good resource to help understand shrinking; how it works, what to consider etc...

rickmoynihan 15:59:35

it seems like quite an involved topic

lucasbradstreet 16:29:18

I’m interested in this. I have a reasonable intuition about it, but I’d like something in more detail

gfredericks 17:01:04

well I can answer specific questions about it at least

gfredericks 17:01:48

for the most part the shrinking strategy mirrors the structure of your generator

gfredericks 17:02:21

e.g., tuple shrinks by shrinking its elements; collections shrink by deleting elements and shrinking elements

gfredericks 17:02:39

fmap shrinks by shrinking the underlying element and running it through the function again

gfredericks 17:09:55

bind is a little weird though, and therefore so is gen/let

gfredericks 18:04:11

@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.

mattly 20:54:18

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

mattly 20:55:10

the idea being that when there are multiple possible values that require different generators, it will shrink along an axis of my choosing

mattly 20:57:32

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

mattly 20:57:38

so I setup the generator like so:

mattly 20:58:08

@mattly uploaded a file: Untitled

mattly 20:58:37

instead of using gen/frequency to mimic the structure of my inputs

mattly 20:59:09

it will definitely test the case where there's a thing, but will shrink towards there not being a thing

mattly 20:59:20

which reduces the noise I have to contend with when troubleshooting a failure

mattly 21:00:56

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

mattly 21:01:43

(and feel free to correct me if I'm wrong – I'm going off of observation from usage and cursory readings of the code)

gfredericks 21:11:08

@mattly: what makes you say gen/frequency doesn't shrink?

gfredericks 21:12:01

oh I see; I'm inclined to say that's a bug

mattly 21:12:14

@gfredericks: my experience of using it, that example before, the frequencies didn't seem to matter when shrinking

gfredericks 21:12:44

I would think it should shrink toward earlier generators like one-of does

mattly 21:12:57

so f.e. [[3 (gen/return nil)] [1 (gen/elements things)]] it'll still pick gen/elements

mattly 21:13:00

that'd be even better

gfredericks 21:13:38

would you like to file the bug or shall I?

mattly 21:14:09

go for it, i don't think I have an account on the jira

mattly 21:14:14

I probably should

mattly 21:14:23

and you'd know more about what to say about it :smile:

mattly 21:18:42

I'm planning to do a writeup on my usage of test.check and property-based testing on the system I'm working on

mattly 21:19:19

there's a lot of material out there on what it is, but very little on how to use it effectively

mattly 21:21:00

this has been such a success on my system, I'm teaching our QA guy how to write generators