Testing Pure Clojure Code

Many Java codebases end up with expensive tests because the real business rule is buried inside constructors, framework wiring, repository calls, and time-dependent behavior. When a test needs five mocks before it can reach the branch you care about, the design is telling you something.

Clojure improves testability when you keep most of the logic in pure functions over plain data. The benefit is not philosophical. It is operational: tests get smaller, failures get clearer, and refactors stop breaking unrelated setup.

Pure Functions Turn Tests Into Simple Examples

A pure function depends only on its arguments and returns a value. That means the test can look like a small executable example:

1(ns my.app.renewals)
2
3(defn renewal-decision [subscription]
4  (cond
5    (:cancelled? subscription) :skip
6    (<= (:days-until-expiry subscription) 0) :expired
7    (<= (:days-until-expiry subscription) 14) :send-reminder
8    :else :wait))

The matching test is direct:

1(ns my.app.renewals-test
2  (:require [clojure.test :refer [deftest is]]
3            [my.app.renewals :as renewals]))
4
5(deftest renewal-decision-test
6  (is (= :send-reminder
7         (renewals/renewal-decision
8          {:cancelled? false
9           :days-until-expiry 7}))))

There is no database setup. No fake clock. No application context. The test is just “given this map, expect this result.”

That style adds up quickly across a codebase. Dozens of tiny tests are easier to maintain than a few integration-style tests pretending to be unit tests.

The Real Design Move: Pure Core, Impure Shell

The biggest win is not “write isolated helper functions.” It is learning to separate the code that decides from the code that performs effects.

1(defn reminder-email [subscription]
2  {:to (:email subscription)
3   :subject "Your subscription is expiring"
4   :body (str "Plan: " (:plan subscription))})
5
6(defn maybe-send-reminder! [send-email! subscription]
7  (when (= :send-reminder (renewal-decision subscription))
8    (send-email! (reminder-email subscription))))

Here the core decision logic stays pure:

• renewal-decision decides what should happen
• reminder-email builds data for the side effect
• maybe-send-reminder! is the small impure boundary that actually sends

That boundary is the only place that needs a test double for email delivery. Everything else can be tested with plain maps.

Here is the corresponding boundary test. Notice that only the effectful function is replaced:

 1(deftest sends-reminder-at-boundary
 2  (let [sent (atom [])]
 3    (maybe-send-reminder! #(swap! sent conj %)
 4                          {:email "dev@example.com"
 5                           :plan :team
 6                           :cancelled? false
 7                           :days-until-expiry 7})
 8    (is (= [{:to "dev@example.com"
 9             :subject "Your subscription is expiring"
10             :body "Plan: :team"}]
11           @sent))))

This is still dependency injection, but the dependency is a single function instead of a tree of services. Most tests should not need even this much machinery; reserve it for the boundary where the side effect happens.

Dependency Injection Still Exists, But It Gets Smaller

Java developers often hear “functional code avoids dependency injection” and assume that means “ignore dependencies.” That is the wrong takeaway.

The better takeaway is:

• inject fewer things
• inject them closer to the boundary
• inject functions or values instead of entire object graphs when possible

Passing send-email! as a function is dependency injection. It is just lighter-weight than constructing a service graph to call one side effect.

Real Data Beats Mock Mazes

Another testability benefit is that Clojure code often accepts ordinary data structures directly. That makes fixtures cheap:

1{:id 42
2 :email "dev@example.com"
3 :plan :team
4 :cancelled? false
5 :days-until-expiry 7}

Compare that with building a nested Java object graph just to express the same test case. In Clojure, the shape of the input is usually visible in the test, which makes the test easier to read and update.

Time, Randomness, And I/O Become Explicit

The easiest way to make tests flaky is to let ordinary functions read time, randomness, or external state directly. Clojure nudges you to make those dependencies obvious:

• pass now in as a value
• pass uuid-fn or rand-fn in as a function
• keep HTTP, DB, and logging calls in small boundary functions

You can still use tools like with-redefs when necessary, but if you need them for most tests, the boundary is probably too broad.

What This Means For Java Engineers

The transition is less about abandoning good testing habits and more about moving the seam to a better place.

In Java, a common seam is between classes:

• service vs repository
• controller vs service
• interface vs implementation

In Clojure, the seam is often between:

• pure decision logic
• side-effecting boundary code

That shift usually reduces both mocking and incidental complexity.

Testing Strategy By Layer

The practical target is not “only unit tests.” It is a portfolio where most business rules are cheap to test and a smaller number of integration tests prove the wiring.

What Testability Does Not Mean

Better testability does not mean:

• every function must be one line long
• you never write integration tests
• side effects are bad
• dynamic code needs no discipline

It means the part of the system that contains your real business decisions is easier to exercise without booting the world around it.

Knowledge Check: Testing Wins