@domkm I think you can use your own predicate in root graph spec (s/and asyclic? (s/keys ...)), which internally uses s/*recursion-limit*, but that would traverse graph twice

Has anyone found a nice workaround for this: https://dev.clojure.org/jira/browse/CLJ-2067? [spec] (s/def ::a ::b) throws unable to resolve error if ::b is not defined

This seems like a silly question, but is there a standard way of checking specs in tests? I suspect it uses (-> (stest/enumerate-namespace 'user) stest/check) and looks something like this:

(deftest specs
  (...
    (-> (stest/enumerate-namespace 'user) stest/check)))

@bmaddy Generative tests can be long-running so having them in "unit tests" that you run all the time is a bit of an anti-pattern.

How do you guys do unit testing? Just what percentage of tests are manually written example based ones?

Hmm, so do people just remember to run a stest/check function that's in a comment after the function every time they update it? That's what I've been doing so far, but I figured there was a better way.

I think check can be useful when writing the function/spec, but for tests, I tend to use test.chuck and write my properties in the test

then I can use chuck/times to control the number of generative tests (low number during development, higher number on CI)

but I don’t tend to write a lot of functions that have super interesting :fn specs, I just check :args and :ret specs in tests

My tests will instrument my functions, then for any input I can just use s/gen to get the generator, use that with test.chuck

I thought test.chuck was a typo. 😂

heh, no, it’s a really useful lib for generative testing 🙂

There's also clojure.test.check.clojure-test/defspec for property-based tests... https://github.com/clojure/test.check/blob/master/src/main/clojure/clojure/test/check/clojure_test.cljc#L74

And, yeah, big +1 for test.chuck -- we love the regex string generator in it!

@bmaddy I think a good option is to have some scripts that run stest/check and summarize/assert the results are good, and then run those scripts directly as part of either periodic manual or full-suite testing (rather than automated/unit test level stuff).

At work we have a few generative tests that run in our "mainline" automated/unit tests, and then we have some more extensive generative/property tests that are in (comment ...) forms in various files that we currently run manually, from time-to-time.

("Rich Comment Forms" -- per Stu's Strange Loop talk)

Thanks @seancorfield. I'd be interested to hear how others do this as well if they feel like sharing.

am I right that the stc namespace for options can only be aliased like:

#?(:clj (alias 'stc 'clojure.spec.test.check))

I think because it doesn’t exist as a file, but is created when loading clojure.spec.test.alpha

that sounds plausible

I didn't know it did that

it’s a bit awkward. trying to think about this: https://dev.clojure.org/jira/browse/CLJS-2952

I think I had a nice solution, but now my ns looks like:

(ns spec-keys-test
  (:require
   [clojure.test :as t :refer [deftest testing is]]
   [clojure.spec.alpha :as s]
   [clojure.test.check]
   [clojure.spec.test.alpha :as stest]
   #?(:cljs [clojure.spec.test.check :as stc])
   ))

#?(:clj (alias 'stc 'clojure.spec.test.check))

maybe changing the clojure version of the alias stc to clojure.test.check makes more sense than the in-ns thing in clojure.spec.test.alpha

Ah I see why that isn’t the case, because clojure.test.check is lazily loaded (optional dep).

Would it be OK if clojure.spec.alpha created an empty ns in a file, instead of the in-ns? Then both requires for cljs and clj could look the same. This would be nice in .cljc.

Posted an issue about this at JIRA