Fairly minimalist example available
at https://gist.github.com/jimrthy/21851c52a8cd6b04a31ed08b1d0a7f04
When I call gen/sample from inside a unit test, it seems to pass with
flying colors.
When I directly eval the gen/sample form or call (manual-check) from the
REPL (I checked both CIDER and the boot CLI, just in case), I usually get
the "Couldn't satisfy such-that predicate after 100 tries."
To be a little more specific about this:
Calling (manual-check) failed 49/50 times.
Calling (transitive-indirect) passed 50 times in a row. If you haven't
bothered looking at the gist, each of those calls (manual-check) 40 times.
I was quite surprised by this. Does anyone have any suggestions about why
wrapping the call in a unit test might help it succeed more often?
If I just call gen/sample on the generator I'm trying to use, followed by
s/valid? for one of the specs I'm trying to generate, it seems fine. I
haven't dug into the source here (and I'm not positive what all's going on
inside the spec.gen namespace), but I thought that's what gen/generate does
when you define a custom generator for your spec.
Except that isn't really what I'm doing.
I'm trying to avoid adding extra runtime dependencies on a library like
tools.check, so I'm trying to do this with overrides in the test namespaces
to try to limit the extra dependencies to test time.
Could that be where I'm breaking core assumptions that don't seem to cause
trouble for anyone else?
Thanks,
James
On Sunday, February 25, 2018 at 6:45:39 PM UTC-6, James Gatannah wrote:
>
> I have a spec for an array of 16 bytes:
>
> (s/def ::extension (s/and bytes?
> #(= (count %) 16))
>
> Then I have a couple of other specs that are really just renaming it:
>
> (s/def ::client-extension ::extension)
> (s/def ::server-extension ::extension)
>
> I started doing some refactoring today, and the definitions wound up
> needing to move to a different namespace.
>
> So now the original definitions have changed to
>
> (s/def ::client-extension ::refactored/client-extension)
>
> I also started dabbling with generators, and came up with this:
>
> (gen/generate (s/gen ::client-extension
> {::client-extension #(gen/fmap
> byte-array (gen/vector (gen/choose -128 127) 16)}))
>
> When I define things this way, I get a "Couldn't satisfy such-that
> predicate after 100 tries." exception a little more than half the time.
>
> If I rearrange things so that either
> a) The refactored namespace defines the spec directly
> or
> b) I change my generator override to specify the top-level spec that the
> others are copying
>
> i.e.
> a) would mean changing the refactored ns such that I have
> (s/def ::client-extension (s/and bytes?
> #(= (count %) 16))
>
> b) changing the generator to
> (gen/generate (s/gen ::client-extension
> {::refactored/extension #(gen/fmap
> byte-array (gen/vector (gen/choose -128 127) 16)}))
>
> it seems to fail (with the same problem) about 1 time in 5.
>
> I haven't seen it fail yet if I undo my refactoring and move the spec back
> to the original location.
>
> I haven't collected any sorts of real numbers on this, much less tried to
> make enough test runs to collect a statistically significant sample. I know
> the next real steps are to put together a minimalist example.
>
> But before I do that, I figured it might be asking whether anyone sees
> anything obviously wrong in what I'm trying to do, or whether there's a
> better way to do it.
>
> Thanks in advance,
> James
>
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to [email protected]
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
