This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-04-27
Channels
- # beginners (35)
- # boot (111)
- # cider (12)
- # clojure (295)
- # clojure-android (2)
- # clojure-dev (12)
- # clojure-dusseldorf (9)
- # clojure-finland (1)
- # clojure-greece (7)
- # clojure-italy (24)
- # clojure-norway (1)
- # clojure-poland (7)
- # clojure-russia (14)
- # clojure-sg (1)
- # clojure-spec (29)
- # clojure-uk (25)
- # clojurebridge (1)
- # clojurescript (157)
- # clr (3)
- # cursive (3)
- # datomic (55)
- # docker (6)
- # hoplon (4)
- # juxt (11)
- # leiningen (13)
- # luminus (1)
- # lumo (3)
- # mount (1)
- # off-topic (47)
- # om (43)
- # onyx (35)
- # re-frame (33)
- # reactive (2)
- # reagent (4)
- # rum (3)
- # schema (5)
- # specter (5)
- # test-check (63)
- # vim (15)
- # yada (14)
Yeah, test.check hopes that the public API is sufficient
I assume you see the bug in your code?
Or, why that function doesn't/ can't work
other than my typo with the wrong variable? and the lack of the “AST interpreter” that would drive that protocol? no, not really
In the fmap str example, you'll be passing a string to a shrinker that expects integers
value is a string, (shrink x ...) wants an integer
Somebody somewhere will have to parse the string
That's ideal, I'm just not sure how you wrap this up into the test runner in an arbitrarily composable way
i’m not even convinced that it makes sense to combine generating and shrinking one-to-one like this
i just assumed that shrinking would be simpler than generating in that the tree would be a subset of the generator tree
for example if you generate an arbitrary number and then filter the even ones, you only want one number shrinker, not two
similarly, for the stateful testing case with shrinking, you almost only want to remove actions, not actually alter the contents of any of those actions
way beyond just generative testing, i’m not a fan of monadic apis in general…. i’d much rather build a generator out of transparent data and then interpret (or compile) that - especially so that i could add more methods beyond just generate/shrink….
I'm not even sure what sort of tree you're imagining
the tree of generators that is returning a pure value (that is, of course, tree shaped)
The shape of generator composition doesn't necessarily mirror the shape of the data
I've thought about generators-as-data, but seems hard to do bind
So test.check has an approach where bind at least works 😛
So you're imagining that the user-facing API for your generators is the protocol of two functions? If so I'm still not seeing how you get around the fmap problem
but the larger problem i have is that, even understanding how it works, i’m not sure how to make effective use of it
if i have random push/pop operations and it’s going to do shrinking, it’s going to waste a bunch of time pushing or popping smaller integers, when really i want to try fewer pops or fewer pushes
Somewhat
It will shrink each integer straight to 0
In one step
Only if that doesn't work does it try other things
So N steps total to accomplish that
But it could also try removing things first, I'm not sure
That depends on which step bind tries first
One downside to this structure is you can't give shrink hints
I think shrinking efficiency is only an issue when generating really large compositions
I suppose I shouldn't say there's no way to give hints; for your example, if it was a problem, you could wrap the integer generator in gen/no-shrink
test.check does this itself for the builtin UUID generator, on the assumption that there's not much to be gained from shrinking a UUID
w.r.t. the earlier question on large-integer boundary testing, that's a more general issue I'm aware of but haven't been sure how clever it should try to be
I've considered rebooting the generators namespace to clean up the API; maybe there could be a partition into lower-level generators and higher-level clever ones
the low level ones do simple easy to understand things, the high level ones do lots of ad-hoc stuff to try to break your code
¯\(ツ)/¯
Hey guys, great discussion here. I think the announcement of hedgehog, a new quickcheck-like library for haskell is very relevant: https://www.reddit.com/r/haskell/comments/646k3d/ann_hedgehog_property_testing/. One of its selling points is that it "uses integrated shrinking, so shrinks obey the invariants of generated values by construction [...] an approach to property testing which is also used by QuiviQ's Erlang QuickCheck, Hypothesis, and test.check"
Oh nice - I forgot about that
@gfredericks: btw I made some progress on the async quick-check. I pushed a draft to my repo today: https://github.com/nberger/test.check/compare/test.check.refactor...refactor-allow-async. I'm working on a defspec-async
macro now that would use that stuff and would make the tests much easier to write (for example it "knows" when to call the done
from cljs.test/async, which is on :succeeded or :shrunk) so the :step-fn that I'm using in the tests would be gone
@nberger someone made a ticket asking for that
yep, saw it. I've been thinking about this for a long time, the ticket made me go to the keyboard and try to make it work, and I'm quite happy with the result so far
cool, let me know and I'll take a look