←back to thread

90 points birdculture | 1 comments | | HN request time: 0s | source
Show context
mjw1007 ◴[] No.43747119[source]
I've found in practice that shrinking to get the "smallest amount of detail" is often unhelpful.

Suppose I have a function which takes four string parameters, and I have a bug which means it crashes if the third is empty.

I'd rather see this in the failure report:

("ldiuhuh!skdfh", "nd#lkgjdflkgdfg", "", "dc9ofugdl ifugidlugfoidufog")

than this:

("", "", "", "")

replies(4): >>43747380 #>>43748889 #>>43749509 #>>43749569 #
edsko ◴[] No.43749569[source]
(Author of falsify here.) You are absolutely correct that the empty string isn't always the best counter-example. The goal of shrinking is to shrink to the _simplest_ possible value (this is true for all approaches to shrinking). What constitutes "simple" is very much domain specific. It would certainly be possible to write a generator that would shrink to, say, "foo", as the canonical "simplest" example of a simple string. Indeed, since we are working in a lazy language, you could (with a bit of effort) shrink to `undefined` if the other arguments are not used at all.
replies(1): >>43749662 #
1. mjw1007 ◴[] No.43749662[source]
I agree it can be domain-specific, but I think it's more common than not that empty containers, and the number zero, are corner cases rather than typical values.

So I think it would be a decent quality-of-life improvement to make generators of the sort you suggest easily available, and have the tutorial docs use them from the start.