with-redefs JVM-global Redefinition Boundary in Parallel Clojure Integration Tests

Answer the Core Questions First

1. Is serialising all credential‑mocked integration tests acceptable?

Serialisation is a quick fix that guarantees isolation because with-redefs changes the var root globally. Running the affected namespaces one after another removes the race condition, but you lose the parallel‑test speed that Kaocha provides. If the test suite is small or the mocked calls are slow, the trade‑off might be tolerable. For larger projects, the slowdown can become a maintenance burden.

2. Does binding give enough isolation when futures or agents are used?

Thread‑local binding works only for the current thread. If your test spawns a future, an agent, or uses core.async, the spawned thread inherits the original var root, not the bound value. Therefore, binding alone does not guarantee isolation for code that captures the var after the test has started a background task.

3. What is the lowest‑effort migration path to inject HTTP clients as function arguments?

Instead of rebinding global vars, refactor your API‑client calls to accept a client function or a protocol instance. Wrap the original client in a var that can be rebound only in the test setup, but capture its value before launching background work. A typical pattern is:

(def ^:dynamic *http-client* (fn [& args] (http-client/req args)))

(defn call-service [& args]
  (let [client *http-client*]   ; capture current value
    (client args)))

In the test you then use with-redefs to replace *http-client* with a mock that returns a predetermined response. Because the mock is captured before any futures are started, background tasks see the mocked client even though the var root is global.

This approach requires only a small change to the test fixtures and the functions that use the client. You can keep the existing test bodies unchanged; only the call sites need to be updated to use the dynamic var or to accept the client as a parameter. If you prefer explicit dependency injection, pass the client as an argument to the functions under test and use a test fixture that supplies a mock.

Practical Verification Steps

• Run clojure -M:test with Kaocha in parallel mode and watch for interleaved log output that indicates a shared mock is being used by multiple threads.
• Add a watch to the var you rebind: (add-watch #'my-var :debug (fn [_ _ _ new] (println "Rebound to" new))) to see when different threads observe the change.
• Create a minimal test that spawns a future inside with-redefs and asserts that the future sees the mocked value. If the future prints the original value, the binding is insufficient.

Missing Diagnostic Detail

To refine the recommendation, it would help to know whether any of your integration tests spawn work on core.async channels, futures, or agents. If so, the capture‑before‑spawn pattern becomes essential.