This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-11-08
Channels
- # aws (3)
- # bangalore-clj (1)
- # beginners (47)
- # boot (137)
- # cider (1)
- # cljs-dev (67)
- # cljsrn (7)
- # clojure (122)
- # clojure-argentina (5)
- # clojure-berlin (4)
- # clojure-czech (12)
- # clojure-france (27)
- # clojure-italy (9)
- # clojure-russia (88)
- # clojure-spec (44)
- # clojure-uk (157)
- # clojurebridge (2)
- # clojurescript (236)
- # datomic (5)
- # devcards (3)
- # dirac (23)
- # emacs (13)
- # hoplon (29)
- # incanter (1)
- # leiningen (41)
- # microservices (1)
- # off-topic (78)
- # om (145)
- # onyx (13)
- # parinfer (8)
- # pedestal (4)
- # planck (15)
- # protorepl (1)
- # re-frame (72)
- # reagent (25)
- # ring (2)
- # specter (23)
- # test-check (9)
- # untangled (106)
- # vim (8)
- # yada (1)
is there any way to tell test.check to give up and just show me the smallest failing result so far after a certain number of iterations?
I've got one failure that I'm having a really hard time tracking down, but it'll run for 100k iterations without settling
@mattly there are a couple tickets surrounding that
@mattly there is also a callback function you can register on the master branch, that would let you "listen" for things as it's shrinking
there's a ticket for a max-shrink-time option, and for capturing C-c interruptions and returning the smallest value so far
I think the latter one is hairy though so I don't know if it will get implemented :/
C-c
would probably be the most useful, so if it turns out to be straightforward I would love to add it
if it's hairy it's probably because of varying details in different repls vs. unix signals when running test processes and that sort of thing