I created https://dev.clojure.org/jira/browse/CLJ-2246 since I'm pretty sure there's a bug.
On Monday, October 2, 2017 at 10:15:53 AM UTC+2, Khalid Jebbari wrote: > > Thanks for the link. It almost works ! The problem I have is that > stest/check returns a map with [:failure false] when it fails, which seems > weird and prevent stest/abbrev-result to add meaningful data to the > reporting. Not sure if it's a bug in spec. > > Just to make things clear : > > - Passing test : > (-> (stest/check 'my.ns/my-fn) first :failure) > => nil > > - Failing test : > (-> (stest/check 'my.ns/my-fn) first :failure) > => false ;; I expected true, and it seems stest/abbrev-result too > > Env : > > [org.clojure/clojure "1.9.0-beta1"] > [org.clojure/spec.alpha "0.1.123"] > [org.clojure/test.check "0.10.0-alpha2" :scope "test"] > > > > On Sunday, October 1, 2017 at 8:00:55 PM UTC+2, avichalp wrote: >> >> Hi Khalid, >> >> Yes, you can get these details in the output. >> I have found these >> <https://gist.github.com/Risto-Stevcev/dc628109abd840c7553de1c5d7d55608> >> helper functions useful for this purpose. >> >> On Friday, 29 September 2017 15:38:57 UTC+5:30, Khalid Jebbari wrote: >>> >>> Hello, >>> >>> I'm struggling to find a way to to use the fdef specs I wrote in >>> clojure.test tests. I can run them fine in the repl with spec/exercise-fn >>> or spec.test/check, really nice when developping by the way. Now that I'm >>> happy with the result I'd like to encode this knowledge in tests to prevent >>> regressions. I don't need more tests that this, not specific property etc. >>> >>> I found no way to plug the spec.test/check in clojure.test or easily >>> reuse fdef specs. test.check/defspec and quickcheck expect properties as >>> their argument. spec/describe return a LazySeq that I found hard to exploit >>> without a lot of manual wiring, parsing and trial-and-errors. >>> >>> If I had to write it by hand, it would look like : >>> >>> (defspec myspec 100 (prop/for-all [one (spec/gen ::first-arg) >>> two (spec/gen >>> ::second-arg)] >>> (is (true? (spec/valid? >>> ::ret-spec (myfunc one two)))) >>> >>> The problem is that it's incomplete with regards to spec possibilities : >>> spec/or, spec/nilable etc. and I use them. Also I the function changes (in >>> any way) the test becomes irrelevant instantly. >>> >>> A colleague resorted to manually calling spec.test/check in clojure.test >>> and manually verifying the output of the function (the :result boolean, the >>> :num-tests etc.). Feels way too manual, and doesn't report the shrunk value >>> as nicely as test.check does. >>> >>> >>> Maybe I missed something completely. spec/describe seems the best bet to >>> introspect the spec and use it in for-all calls. But still too manual. >>> >>> Any help much appreciated. >>> >> -- 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.
