Clojure Q&A - Recent questions tagged test.check

Rose Tree Children Appear to be Eagerly Evaluated (Clojure 1.12+)

Mon, 31 Aug 2026 18:18:35 +0000

To make a long story shorter, I've been aggressively profiling the generative tests I rely on on a daily basis. In CI, they run on memory-constrained machines which have occasionally ended up in OOM states that cause our test executor to kill the nodes running some generative tests. In many cases, we've been able to adjust sizing to get under the line and resume normally. I've been running into that case more frequently, and have been looking for potential causes/levers to adjust in the source code.

The below findings are from my relatively powerful Macbook:

Operating System: MacOS (Tahoe - AArch64)
Clojure version: Verified on 1.12.1, Compared against 1.11.4
JDK vendor and version: OpenJDK 21.0.11

Using clj-async-profiler and an allocation/timing macro from Clojure Goes Fast, I benchmarked clojure.test.check.generators against some pretty common generators (Assume I'm using gen as an alias for that namespace):

gen/string
gen/large-integer
(gen/map gen/keyword gen/string)

While benchmarking, ReentrantLock (and ReentrantLock$NonfairSync), accounted for ~1/3rd of all allocations. Since Clojure 1.12, each LazySeq also allocates a ReentrantLock, so I reran the benchmarking after downgrading to Clojure 1.11.4 Obviously, all of those object references were no longer in the profiler results, but the amount of bytes allocated did consistently shrink (~10-15%, depending on the generator).

Most of the allocation appears to be happening while constructing the children segments of nodes in the rose tree. To my knowledge, we only ever lean on the full tree when shrinking results, and wouldn't read them on a generate-only pass. To test that, I wrapped the children arguments to a few of the make-rose calls in the call tree for string generation, and re-instrumented on v.12.1

This approximated the same reduction in memory use as downgrading to 1.11.4, and wiped out almost all of the ReentrantLock allocation events. I've been able to verify the fix does not break any tests, and that shrinking is functional as well.

For posterity / reproduction, the specific call sites I wrapped the children in were:

clojure.test.check.rose-tree
- join
- fmap
- shrink
- shrink-vector*
clojure.test.check.generators
- int-rose-tree

Happy to share the profiler output / git patch if anyone is interested!

`(s/gen ...)` caches its failure to load generators and thus is incompatible with `add-lib`

Tue, 23 Sep 2025 16:23:58 +0000

Clojure 1.12.0
user=> (require '[clojure.spec.alpha :as s])
nil
user=> (s/def ::x #{1 2 3})
:user/x
user=> (s/gen ::x)
Execution error (FileNotFoundException) at user/eval145 (REPL:1).
Could not locate clojure/test/check/generators__init.class, clojure/test/check/generators.clj or clojure/test/check/generators.cljc on classpath.
user=> (add-lib 'org.clojure/test.check)
[org.clojure/test.check]
user=> (s/gen ::x)
Execution error (FileNotFoundException) at user/eval145 (REPL:1).
Could not locate clojure/test/check/generators__init.class, clojure/test/check/generators.clj or clojure/test/check/generators.cljc on classpath.

How to suppress/capture the output of defspec for use in clojure.test?

Tue, 06 Aug 2024 20:41:33 +0000

I've been a fan of test.check since the beginning. However, I've never found a convenient way to capture the output when using defspec. When used with clojure.test, one gets output that looks like:

Testing tst.tupelo.y64 {:result true, :num-tests 999, :seed 1722976402694, :time-elapsed-ms 53, :test-var "dospec-line-53"} {:result true, :num-tests 999, :seed 1722976402747, :time-elapsed-ms 36, :test-var "dospec-line-44"}

somewhat polluting the unit test output. How can one capture and/or suppress this output?

Add option to enable automatically running tests when form is evaluated

Thu, 26 Jan 2023 11:29:13 +0000

Libraries like RCF support a programming style where tests are written inline with the source code and always run when the test form is evaluated (for example if the file is reloaded) for fast feedback and better locality of tests and examples - small example tests sit next to the code, and unlike comment blocks, are at lower risk of going out of sync with the code base.

This way, forms wrapped with with-tests, deftest and set-test will run their tests when they're evaluated.

This isn't suitable for long running or heavy tests, which is why having a dynamic var which could be set per namespace seems like a decent fit.

RCF achieves it by always adding a call to test-var at the end of the test form:

e.g.

(when *run-tests* `(test-var (var ~name)))

Then tests written inline with code will be able to run automatically when code is loaded and provide immediate feedback

Alternative: use tools.namespace

Thouhghts?

CLJS compilation warnings from `test.check` for undeclared Var in `goog.math.Long` from clojure.test.check.random.longs

Thu, 29 Apr 2021 22:22:21 +0000

When compiling test.check version 1.1.0 with Clojurescript version 1.10.844, I'm seeing warnings about the following missing vars from goog.math.Long:

WARNING: Use of undeclared Var goog.math.Long/fromBits at line 64 file:~/.m2/repository/org/clojure/test.check/1.1.0/test.check-1.1.0.jar!/clojure/test/check/random/longs.cljs
WARNING: Use of undeclared Var goog.math.Long/fromString at line 77 file:~/.m2/repository/org/clojure/test.check/1.1.0/test.check-1.1.0.jar!/clojure/test/check/random/longs.cljs
WARNING: Use of undeclared Var goog.math.Long/fromNumber at line 81 file:~/.m2/repository/org/clojure/test.check/1.1.0/test.check-1.1.0.jar!/clojure/test/check/random/longs.cljs
WARNING: Use of undeclared Var goog.math.Long/fromNumber at line 87 file:~/.m2/repository/org/clojure/test.check/1.1.0/test.check-1.1.0.jar!/clojure/test/check/random/longs.cljs
WARNING: Use of undeclared Var goog.math.Long/getOne at line 92 file:~/.m2/repository/org/clojure/test.check/1.1.0/test.check-1.1.0.jar!/clojure/test/check/random/longs.cljs

I believe this showed up after the recent CLJS release, so maybe related to deprecations in the namespaces provided by the latest version of the Google Closure Compiler or associated libraries?

Generating a function invokes the function

Sat, 06 Mar 2021 21:55:46 +0000

I was experimenting with custom function generators in order to support the scenario describe in spec guide https://clojure.org/guides/spec#_combining_check_and_instrument but with the goal of making the generated values depend on the concrete arguments and not only on the :ret spec.

While working on that, I noticed a weird behavior that I fail to understand where a generated function is being called 21 times before actually being returned.

(require '[clojure.spec.alpha :as s]
         '[clojure.spec.gen.alpha :as gen])

(s/fdef foo
  :args (s/cat :x int?)
  :gen #(gen/return
         (fn [& argv]
           (prn argv)
           (gen/generate (s/gen string?)))))

(gen/generate (s/gen `foo))
;; Prints:
;; (-1)
;; (-1)
;; (-2)
;; (-1)
;; (3)
;; (-2)
;; (-2)
;; (-1)
;; (-35)
;; (14)
;; (-16)
;; (26)
;; (-17)
;; (150)
;; (0)
;; (-1)
;; (25)
;; (5638)
;; (543)
;; (57)
;; (257)
;; Returns: #function[fspec-gen-bug.core/fn--6577/fn--6578]

This behavior seems specific to function generation for example

(s/def ::bar
  (s/spec (s/coll-of int?)
          :gen #(gen/return
                 (doto [(gen/generate (s/gen int?))]
                   prn))))

(gen/generate (s/gen ::bar))
;; Prints:
;; [438803]
;; Returns: [438803]

Is there a good reason why generated functions are invoked eagerly ? or is it a bug ?

Clarify the position of :/ as a keyword

Thu, 09 Jul 2020 06:36:27 +0000

The Clojure and Clojure reader both accept :/ as a keyword, and test.check generates it. From what I could gather from conversations on Slack however it does not seem to be officially considered valid. For example in this thread, which mentions there was an earlier discussion in clojure-dev, but unfortunately I was not able to find it.

It was suggested to remove it from test.check (TCHECK-155) which was closed with a call to authority and quote from Alex Miller, however Alex has also stated that he considers this a test.check bug.

The quote in TCHECK-155 also mentions that "clojurescript should fix its weirdness", but I could not find the original conversation so I'm not sure what this refers to or if there's a ticket. I did find that clojurescript behaves differently than clojure in at least one way

(name (keyword "/")) ;;clj => "" ;;cljs => "/"

I guess my question is, is :/ considered a) valid, b) invalid, or c) undefined / left for future expansion, in EDN and/or in Clojure?

If it is a) valid, is it then safe to say that (name (keyword "/")) is a clojurescript bug?

If it is b) or c), does that mean that TCHECK-155 should be reopened?

Thanks!