I’m trying to run stest/check for my entire coebase. It’s failing, but I can’t tell which thing is failing. All I get is:

ExceptionInfo Couldn't satisfy such-that predicate after 100 tries.  clojure.core/ex-info (core.clj:4725)

It’s also not clear how I run this as part of clojure.test; puting it in the toplevel of a ns doesn’t work (`lein test` doesn’t pick it up) — wrapping it in a deftest makes lein test see that ns as a test ns, but doesn’t seem to run the actual checking (no exception)

I only get the exception when manually evaling stest/check in a repl

The generative testing behind check is / should be very different from your unit testing with clojure.test...

... you should see something in the stacktrace explaining which identifies which spec's generator is unable to satisfy the predicate ...

... as you're writing specs, you probably want to exercise them to make sure the generators are working as expected: that would help you find problems like the one above as you created each spec. Not sure whether that's helpful advice @lvh?

@lvh that particular error means that your generator can't produce something that matches your spec. i had this when i tried to s/and two s/keys together; it would generate for the first keys and never find anything that satisfied the second keys

robert-stuttaford; yep; I know what the error means, but I have more than 1 spec

@seancorfield: I’ve manually arrowed it down to a particular spec; and gen/sample + s/gen works fine

@seancorfield: I’ve used test.check before: is the generative testing behind check different enough to not want to run it as part of lein test? Because that’s how I run my normal generative tests

Also, judging by the Guide, just running all the tests for all the namespaces is an explicitly supported feature

Is there any intention to make named? publicly available as a predicate such that s/and can maybe take advantage of if? Ideally also not-named 🙂

Use ident?

That was added to core (named? really needs to be replaced in that code)

And #(not (ident? %))

:)

oooh found another thing that clojure allowed before specs were added: (fn a/b [])

which can easily be accidentally coded in situations like this: https://github.com/palletops/lein-shorthand/blob/06699b908df43a3029d6ef91b7591f17017a0405/src/com/palletops/shorthand.clj#L13

Yeah, I fixed a bunch of those, nearly always in a sloppy macro

algo.monads is actually broken on alpha11 due to a similar problem but with defn

@lvh I'm basing those comments on what Rich and others have said about generative testing not being part of "normal" (fast) unit testing.

Like you, in the past, what little generative testing we've done has been okay in our regular Expectations-based test suite. But with the much more extensive use of generative testing in spec.test/check that is not a realistic approach. Unit tests should give near-immediate feedback and take "seconds" to run overall. Generative testing takes much longer so it needs a different approach.

Sure, that makes sense; I still want to run the tests as part of a test suite even if it isn't the fast, rapid-feedback one though :)

I’m seeing a lot of failures with stest/check like:

6. { :failure clojure.lang.ExceptionInfo: No fn to spec #:clojure.spec{:failure :no-fn}, :sym clojure.core/ns, :spec clojure.spec$fspec_impl$reify__13891@283add16 }
  7. { :failure clojure.lang.ExceptionInfo: No fn to spec #:clojure.spec{:failure :no-fn}, :sym clojure.core/defn, :spec clojure.spec$fspec_impl$reify__13891@59681966 }

Looks buggy to me

@alexmiller: I’m guessing that means “you should go file a bug?” 🙂

Also probably something for core.typed to stop using versions of core.contracts that pull in old versions of core.unified that no longer work 🙂

has anyone been working on a macro that combines defn and fdef, in a similar way to schema’s defnk?