by Michael Gaare

Previously in Part 1 and Part 2, we looked at some problems with using globals for stateful components in Clojure, and an approach to solving this problem using local, scoped state managed with Stuart Sierra’s Component library.

A few people pointed out that I failed to deliver on the promise of showing how this approach helps with testing. From the outside it may look as though I simply forgot to include this part, and in a startling display of poor priorities I spent my time writing a deranged dream sequence instead. It might look that way! But in the best tradition of a certain prominent politician, I boldly claim that my so-called “mistake” was completely deliberate — merely a part of my grand plan — and it is you who are mistaken.

So let’s take a look at testing these things.

Simple Web Handler Test

Remember in Part 1, there was this simple test of a web handler that uses a database from the global state:

(deftest homepage-handler-test

(with-bindings {app.db/*db-config* test-config}

(is (re-find #"Hits: [0-9]." (homepage-handler {})))))

We re-wrote our database connection as a record in the Component style, implementing a DBQuery protocol, like this:

(defprotocol DBQuery

(select [db query])

(connection [db])) (defrecord Database

[config conn] component/Lifecycle

(start [this] ...)

(stop [this] ...) DBQuery

(select [_ query]

(jdbc/query conn query))

(connection [_]

conn)) (defn database

"Returns Database component from config, which is either a

connection string or JDBC connection map."

[config]

(assert (or (string? config) (map? config)))

(->Database config nil))

We also re-wrote our web app as a component that gets the database record injected in, like this:

(defrecord WebApp

[database]) (defn web-app

[]

(->WebApp nil)) (defn web-handler

[web-app]

(GET "/" req (homepage-handler web-app req)))

This gives us several ways to test our web app and handler functionality. First, we can duplicate the original test logic that uses a testing database.

(def test-db (atom nil)) (defn with-test-db

[f]

(reset! test-db (component/start (database test-config)))

(f)

(component/stop @test-db)) (use-fixtures :once with-test-db) (deftest homepage-handler-test

(let [test-web-app (assoc (web-app) :database @test-db)]

(is (re-find #"Hits: [0-9].") (homepage-handler test-web-app {}))))

If we don’t want to use an actual database to test against, we can also mock the functionality we need in a mock database component.

(defrecord MockDatabase

[select-fn] DBQuery

(select [_ query]

(select-fn query))

(connection [_]

nil)) (defn mock-database

"Returns a mock database component that calls select-fn with the

passed in query when DBQuery/select is called."

[select-fn]

(->MockDatabase select-fn)) (deftest homepage-handler-test

(let [mock-db (mock-database (constantly {:hits 10}))

test-web-app (assoc (web-app) :database mock-db)]

(is (re-find #"Hits: 10" (homepage-handler test-web-app {})))))

Testing the Image Workers

A lot of this code can be re-usable in testing the image worker component, which also uses a database connection. The code for this component is a bit longer, so refer to Part 2 if you need a refresher. It’s very straightforward to write a test for it that uses the test database from our previous example.

(deftest image-worker-test

(let [... insert some tasks into the test db ...

test-image-worker (component/start

(assoc (image-worker {:workers 2})

:database @test-db))]

(Thread/sleep 2000)

(is (... check if the test-db's tasks were completed ... ))

(component/stop test-image-worker)))

Also observe that we’ve hard-coded the idea that the task queue is in the database into our image worker component. This too could be improved by turning it into its own component with its own protocol API.

(defprotocol TaskQueue

(next-task [this]

"Returns the next task in the queue, or nil if no task is in the queue.")

(complete-task [this task]

"Sets task as complete.")) (defrecord DBTaskQueue

[config db] TaskQueue

(next-task [this]

(database/select db ...))

(complete-task [this task]

(let [conn (database/connection db)]

(jdbc/with-transaction ...))))

This lets us flexibly mock out the task queue for testing components that use it.

(defrecord MockTaskQueue

[tasks] TaskQueue

(next-task [this]

(let [[nxt & rst :as ts] @tasks]

(if (compare-and-set! tasks ts rst)

nxt

(recur))))

(complete-task [this task]

true)) (defn mock-task-queue

"Takes collection of tasks, returns mock task queue."

[tasks]

(->MockTaskQueue (atom tasks))) (deftest image-worker-test

(let [tq (mock-task-queue [test-task1 test-task2])

test-image-worker (component/start (assoc (image-worker {:workers 2})

:database tq))]

(Thread/sleep 2000)

(is (... check if the test task images were processed ...))

(component/stop test-image-worker)))

One thing that was skipped over in the discussion in the previous articles was the fact that the image workers are doing side effects other than touching a database. They make a call to an `add-watermark` function, which presumably reads the image, does processing of some kind, and re-saves it somewhere. The testability of this, too, could be improved by converting it into a component which could be mocked out or redefined for tests of the image worker.

Test Systems

It’s possible to take this test style even further, and build complete Component system maps for our testing. To refresh our memory, a component system map is a structure that defines all the components in our system, describes their dependencies, and can start them in order and pass in dependencies to return a running system.

In Part 2, we built a system that includes a web server, web handlers, and database. Let’s look at defining a system-wide test.

(def test-system

(component/system-map

:db (database test-db-config)

:web-app (component/using (web-app) {:database :db})

:web-server (component/using (immutant-server {:port 8990})

[:web-app]))) (deftest system-test

(let [started-system (component/start test-system)

test-response (http/get "http://localhost:8990/")]

(is (re-find #"Hits: [0-9].") (:body test-response))

(component/stop started-system))

Advantages

The most natural way to work in Clojure — as a functional language with a fantastic REPL-driven workflow — is to call functions and control their behavior by passing them arguments. This enhances our workflow in development, and also gives us flexible and straightforward ways to test our code.

A component-driven code style provides the same kind of leverage when dealing with areas of our systems that deal in side effects, state, and external systems. Access to controlling the behavior of these components is through passing them different arguments on construction, and passing in different dependencies. This delivers the same kinds of benefits as pure functions, while isolating side effects and state.

The Recap

I wrote this series because when I started in Clojure the process of building clean systems was painful. There wasn’t a community consensus on how to manage stateful resources and there certainly wasn’t a framework I could leverage. My goal was to give the guide I wish I had; concepts could be tied together and beginners could experience the joy of Clojure even earlier than I did.

In this series, we looked at a few strategies for managing stateful resources in the global environment and some problems these approaches cause for interactive development and testing. Then we had a nightmare about being complected by kittens. Then we looked at a design pattern using Stuart Sierra’s component library for managing stateful resources in a local scope with dependency injection. Lastly, we looked at some strategies for testing components built in this style.

After reading this series, I hope you see the beauty I see in building clean systems in Clojure using components. Go forth and build, and may the kittens always be in your favor.

Original article at Engineering Ladders