Lambda Island

Learn how to use a headless web browser to test your application for feature completeness. You’ll also see how Component can be used to set up an isolated test environment, how to use fixtures and dynamic var bindings to share setup code between tests, and how to keep tests readable and concise by judicously pulling code into helper functions.

Transcript

When talking about automated software testing, the phrase most commonly used is “unit testing”. The idea is that you slice your program in small, self-contained “units”, be it modules, functions, classes; and that you test each unit in isolation (to the extent that that’s possible).

Testing small units helps you to be exhaustive. You can mentally go over each line of code and ask yourself, “do I have a test for this?”. You can look at each input and ask yourself what the range of possible values is for that input, and which the edge cases to look out for.

But just because units work on their own doesn’t mean they work together. They need to work together with other units to get actual work done, these could be other parts of your code, or libraries and services provided by other parties. Verifying that they sing in harmony is done with integration tests.

In this way tests form a spectrum, from placing one tiny piece under a microscope, then zooming out and considering bigger and bigger chunks of your application, until you are finally looking at the system as a whole. You have become an outside observer, pressing the buttons on the box to see what happens.

This is where you find out if the features you implemented actually work, and when they do you’re done, and your app is ready to ship. This is why these are called “acceptance tests”. These are the polar opposite of unit tests. Being exhaustive is no longer possible, the amount of possible states and inputs, the possible permutations of incoming events are simply too large, while tests at this level tend to be slow. Instead you write a test for each feature or use case, each task a person using the app might want to achieve.

In this episode I’m going to write acceptance tests for the Booklog application first featured in episode 28 about Authentication with Buddy. I’ll be using SparkleDriver, a Clojure interface to control a headless WebKit browser. Sparkledriver’s requires Java version 8 or later, since it relies on the embedded browser which ships with recent versions of JavaFX. SparkleDriver is just a thin Clojure wrapper library, most of the API it uses is provided by a Java library: jBrowserDriver.

To get started, grab the booklog application off Github, and check out the ep34-start branch.

~ $ git clone https://github.com/lambdaisland/booklog.git
Cloning into 'booklog'...
remote: Counting objects: 255, done.
remote: Compressing objects: 100% (12/12), done.
remote: Total 255 (delta 1), reused 13 (delta 1), pack-reused 238
Receiving objects: 100% (255/255), 63.48 KiB | 0 bytes/s, done.
Resolving deltas: 100% (91/91), done.
Checking connectivity... done.
~ $ cd booklog
~/booklog $ git checkout ep34-start
Branch ep34-start set up to track remote branch ep34-start from origin.
Switched to a new branch 'ep34-start'
~/booklog $

Sparkledriver has already been added to project.clj, together with anything else you’ll be needing for this episode.

(defproject booklog "0.1.0-SNAPSHOT"
  :dependencies [,,,
                 [sparkledriver "0.1.10"]]
  ,,,)

Spin up a REPL, and launch the application with (go). It would be best if you can get a REPL connected to your editor so you can work from a buffer, What I’ll be showing really benefits from having that kind of interactive workflow.

user> (go)
Figwheel: Starting server at http://0.0.0.0:1235
Figwheel: Watching build - app
Compiling "resources/public/js/compiled/booklog.js" from ["src/cljs" "src/cljc"]...
Successfully compiled "resources/public/js/compiled/booklog.js" in 3.686 seconds.
Figwheel: Starting CSS Watcher for paths  ["resources/public/css"]
Garden: compiling #'booklog.styles/style
Wrote: resources/public/css/style.css
Garden: watching /home/arne/github/booklog/src/clj/booklog/styles.clj
:started
user>

Lately I’ve started adding a repl directory to my projects, where I put scratch files that I use to enter forms and send them to the REPL. This directory is not on Clojure’s load path, since these files are not meant to be loaded wholesale. I find this structure encourages me to explore, and it makes it easy to keep a log of my tinkering, which often turns out to be handy later on.

.
├── dev
│   └── user.clj
├── project.clj
├── README.md
├── repl
│   └── sparkledriver.clj
├── resources
│   ├── log4j.properties
│   └── public
├── src
│   ├── clj
│   ├── cljc
│   └── cljs
├── system.properties
└── test
    ├── clj
    ├── cljc
    └── cljs

I already added a repl/sparkledriver.clj file to the project, with a namespace declaration at the top. The namespace isn’t really necessary in this case, since you won’t be requiring the file, but I tend to add one anyway, to provide some kind of isolation.

(ns repl.sparkledriver
  (:require [sparkledriver.core :as sd]))

In CIDER this has the effect that any form evaluated in this file is executed in this repl namespace. Without it it defaults to whatever namespace your REPL is currently in, which initially is user.

(ns repl.sparkledriver)

*ns* ;;=> repl.sparkledriver

;; (ns repl.sparkledriver)

*ns* ;;=> user

I also already required the core SparkleDriver namespace, aliased to sd.

(ns repl.sparkledriver
  (:require '[sparkledriver.core :as sd]))

To start using SparkleDriver, you first need to create a browser instance with make-browser. At the end when you’re done with it you can free up the resources it’s using with close-browser!.

Remember that this is a full WebKit browser. Some rough measurements show that a freshly instantiated browser takes up about 130MB of memory, which I guess in today’s browser landscape isn’t all that bad, but still you don’t want to leak these by the dozen.

(def browser (sd/make-browser))
,,,
(sd/close-browser! browser)

There’s also a with-browser macro, which is similar to Clojure’s with-open. It makes sure that the browser is closed as soon as it goes out of scope. This is generally a good idea, but for this REPL based stuff it’s nice to keep the browser instance around in a var.

(sd/with-browser [browser (sd/make-browser)]
  ,,,)

The fetch! function is the equivalent of typing a URL into the address bar and hitting enter. Once the page has loaded you can then use links and forms to navigate. The return value of fetch! is again the browser instance, allowing you to chain calls. Note that this is a single, mutable browser object. The browser instance that you pass to fetch! is the same one that comes out of it, except that its internal state has changed.

(sd/fetch! browser "http://localhost:1234")
;;=> #object[com.machinepublishers.jbrowserdriver.JBrowserDriver 0x392d747e "com.machinepublishers.jbrowserdriver.JBrowserDriver@392d747e"]

You can see that it’s an instance of JBrowserDriver, which is the library SparkleDriver uses under the hood. It’s a so-called “headless” browser, meaning there’s no GUI to interact with. Instead you control it through code. But being headless can make it hard to see where you’re going. You can find out though, if you know how to ask.

With (current-url) you can see the contents of the address bar, and (page-source) returns the full HTML contents of the page you’re “looking” at. With (page-text) you get just the visible text back. Finally if you really want visual, you can take a screenshot. The (screenshot) function returns the path to the image file. You can combine this with Clojure’s browse-url to immediately pop up an image viewer.

(sd/current-url browser)
;;=> "http://localhost:1234/"
(sd/page-source browser)
;;=> "<html><head><meta content=\"width=device-width, initial-scale=1\" name=\"viewport\">..."
(sd/screenshot browser)
;;=> "/tmp/screenshot7524621746679777593.png"

(require '[clojure.java.browse :refer [browse-url]])
(browse-url (sd/screenshot browser))

Now that the first page is loaded you can start “clicking” around. First you use one of the finder methods to find the Element you want to click on. find-by-css is very useful since you might already be familiar with CSS selectors.

When you found the element you can use click! to actually click on it. As you can see we’ve now navigated to the log in page.

You can also use XPath expressions to find elements. XPath was developed as part of XML, and it’s very powerful, allowing you to do many things that CSS still can’t.

(sd/click! (sd/find-by-css browser "a.log-in"))
(sd/click! (sd/find-by-xpath browser "//a[text()='Log in']"))
(sd/current-url browser)
;; => "http://localhost:1234/login"

These finders always return the first match, or throw an exception when no match is found. There are also variants of these functions with their names ending in an asterisk. These return a collection of all elements that match, which may be empty.

Finally there are specific finder functions for finding an element by its tagname, id, or class, and these too have wildcard variants.

sd/find-by-css*
sd/find-by-xpath*

sd/find-by-tag
sd/find-by-id
sd/find-by-class

sd/find-by-tag*
sd/find-by-id*
sd/find-by-class*

That’s enough SparkleDriver to get you started, let’s get busy on those tests. You’ll find two files under the test/clj/booklog directory: acceptance_test.clj, and test_helper.clj.

Before you can run tests you need to have a system to test against. There’s already a system running, the one that you started from the REPL with (go), but I’m going to set up a separate system that gets started and torn down as part of each test run. This way the tests are independent of the state of the REPL.

(keys reloaded.repl/system)
;;=> (:spicerack :routes :middleware :handler :http :figwheel-system :css-watcher :garden-watcher)

This is a fairly standard Ring-based project. The overall application structure is defined in booklog.application, where an app-system function uses Stuart Sierra’s Component to create a system map.

The argument to app-system is a map of configuration options, at the moment it allows you to set the HTTP port, and the path to the database.

As a data store it uses Spicerack, which lets you store maps of Clojure values simply in a file on the filesystem.

(ns booklog.application
  (:gen-class)
  (:require [com.stuartsierra.component :as component]
            ,,,))

(defn app-config []
  {:http-port 1234
   :db-path "./booklog.db"})

(defn app-system [config]
  (component/system-map ,,,))

For testing you can reuse the app-system function, but configure it differently.

The test configuration will make sure the test system uses a different HTTP port to listen on, and that it uses an different database path. This way tests always start with a clean slate, and don’t interfere with the development system. I’ll use a little helper function defined in booklog.util to generate a unique pathname for the database file.

(ns booklog.test-helper
  (:require [booklog.util :as util]))

(def test-http-port 59800)

(defn test-config []
  {:http-port test-http-port
   :db-path (util/temp-file-name "test" "db")})

clojure.test lets you write “fixtures”, these are functions that prepare the stage for the test to run, and clean things up afterwards. I’ll write such a fixture function to set up and tear down the test system. It’s called wrap-test-system because it “wraps” the tests, Its argument is a function which runs the actual tests, so that you can control what happens before or after.

So in a let block create a test system configuration map. app-system turns it into a SystemMap, which you start with component/start. The result being the updated system. Now the web server and database are and running, and you can invoke the tests. When the tests are done you stop the system again. This will still leave the Spicerack database file lying around, so let’s delete that one as well.

(ns booklog.test-helper
  (:require [booklog.util :as util]
            [booklog.application :as app]
            [com.stuartsierra.component :as component]
            [clojure.java.io :as io]))

(defn test-config [] ,,,)

(defn wrap-test-system
  "A fixture function which sets up the system before tests and tears it down afterwards."
  [tests]
  (let [config (test-config)
        system (-> config app/app-system component/start)]
    (tests)
    (component/stop system)
    (io/delete-file (:db-path config))))

Now in the test file I’m requiring both clojure.test and booklog.test-helper with :refer :all, so all those functions are immediately available. The first one provides use-fixtures, while the second one contains our own wrap-test-system.

use-fixtures takes a keyword followed by one or more functions. The keyword can be either :once, meaning these fixtures are called once for all tests in the namespace, or :each meaning they get called again for each individual test.

(ns booklog.acceptance-test
  (:require [clojure.test :refer :all]
            [booklog.test-helper :refer :all]
            [sparkledriver.core :as sd]))

(use-fixtures :once wrap-test-system)

use-fixtures works by changing the namespace’s metadata, adding either a :clojure.test/each-fixture or :clojure.test/once-fixture key. You can pass multiple functions to use-fixtures, and it will correctly combine them, but if you call use-fixtures multiple times with the same keyword, then the last call will overwrite any previous calls.

(:clojure.test/once-fixtures
 (meta *ns*))
;;=> (#function[booklog.test-helper/wrap-test-system])

At long last you are now ready to start writing a test. This is standard stuff, use the deftest macro to define sign-up-test. You’ll need to create a browser instance with make-browser, and then use with-browser to make sure it gets closed again.

Let’s just visit the home page, and print out all text on the page, just to see how we’re doing.

(deftest sign-up-test
  (sd/with-browser [browser (sd/make-browser)]
    (sd/fetch! browser "http://localhost:59800")
    (println (sd/page-text browser))))

Run it with (run-tests), You can pass it a namespace it needs to test, but if you don’t give it any arguments it just runs all tests in the current namespace. Now keep an eye on the REPL, as that’s where you’ll see the test output.

Cool, that seems to work! Here you can see the page text.

If you get a big noisy error message from jBrowserDriver at the start then don’t panic. There seems to be a known issue with jBrowserDriver printing out an error message when starting a new browser. While annoying, it doesn’t seem to stop the browser from working as expected.

(run-tests)
;; Testing booklog.acceptance-test
;; Booklog
;;
;; TimelineLog in
;; Timeline
;;
;; Ran 1 tests containing 0 assertions.
;; 0 failures, 0 errors.

Before moving on I’m going to pull some more things into helper functions. Because of the nature of these tests I really want them to be easy on the eyes. These tests document the features of the app. You have to imagine they are scripts you could give to a QA person. They need to tell a story.

For starters let’s pull out that browser setup into another fixture function, storing the browesr instance in :dynamic var. This is a var which has {:dynamic true} in its metadata, and which has a name with asterisks around it, colloquially known as “earmuffs”. Clojure will complain if you use the earmuffs without declaring a var as :dynamic, or vice versa.

(def ^:dynamic *browser* nil)

Let’s call this fixture wrap-browser, to stick with the same naming convention. I’m using the same pattern I showed before, using with-browser and make-browser to get hold of a browser instance. Inside there I’m using binding to assign the browser instance to the dynamic *browser* var.

binding is like a special kind of let, but where let assigns local variables and makes them accessible in the current lexical scope, binding dynamically rebinds the var, temporarily giving it a value which can be seen from any code running in the same thread.

Just like with let, the assignment ends when you leave the scope of the binding block.

(ns booklog.test-helper ,,,)

(def ^:dynamic *browser*)

(defn wrap-browser [tests]
  "A fixture function which binds *browser* to a new browser instance."
  (sd/with-browser [browser (sd/make-browser)]
    (binding [*browser* browser]
      (tests))))

Add wrap-browser to the use-fixtures call. When passing in multiple functions like this, they wrap the tests in reverse order, so the first function ends up on the “outside” of the onion, meaning it gets to initialize things first, and clean up last.

(use-fixtures :once wrap-test-system wrap-browser)

This makes it possible to access the current browser instance from helper functions. The plan is to define our own versions of some of the SparkleDriver API, where the browser argument can be omitted. Take fetch!, normally it would take a browser and a url, but our version can also take just a URL, because it already has a browser to work with.

(defn fetch!
  ([url]
   (sd/fetch! *browser* url))
  ([browser url]
   (sd/fetch! browser url)))

Let’s do the same for find-by-css, find-by-xpath, and page-text. They all get a version where you pass the browser in explicitly, and one where it implictly uses the dynamic *browser* var.

(defn find-by-css
  ([css]
   (sd/find-by-css *browser* css))
  ([browser css]
   (sd/find-by-css browser css)))

(defn find-by-xpath
  ([xpath]
   (sd/find-by-xpath *browser* xpath))
  ([browser xpath]
   (sd/find-by-xpath browser xpath)))

(defn page-text
  ([]
   (sd/page-text *browser*))
  ([browser]
   (sd/page-text)))

Finally I’ll add two helpers to deal with URLs. In the tests you don’t really want to care about the domain and port of the application, it’ll always be the same, what you care about is the part that comes after that, the “path”. app-url takes such a path, and returns a full URL, something you could pass to fetch!.

I’m making use of the lambdaisland.uri library to easily manipulate the URL. It’s already required in the namespace, aliased to uri.

(ns booklog.test-helper
  (:require ,,,
            [lambdaisland.uri :as uri]))

(defn app-url [path]
  (assoc (uri/uri "http://localhost")
         :port test-http-port
         :path path))

(app-url "/login")
;;=> "http://localhost:59800/login"

current-path is kind of the opposite, once you’ve browsed around, what is the path of the application you ended up at? Again I’m using lambdaisland.uri to parse the current browser location, and pull out just the path.

(defn current-path []
  (:path (uri/uri (sd/current-url *browser*))))

Now let’s use those helpers in the test. First of all the with-browser macro can go, that’s now being handled by the wrap-browser fixture. The custom versions of the SparkleDriver functions that are defined in booklog.test-helper are required directly, so just remove the sd namespace prefix, as well as the browser argument.

Finally instead of hardcoding the home page url, you can use app-url. This is a bit more robust, if for instance you want to run this on a different port it’ll be easier to change.

(ns booklog.acceptance-test
  (:require [clojure.test :refer :all]
            [booklog.test-helper :refer :all]
            [sparkledriver.core :refer [click! send-text!]]))

(use-fixtures :once wrap-test-system wrap-browser)

(deftest sign-up-test
  (fetch! (app-url "/"))
  (println (page-texot)))

I want to add a test for the sign up process, so let’s see what that looks like.

From the home page you navigate to the registration page, first by clicking on “log in” and then on “Register instead”. Then you fill in and submit the username and password, and if all went well there should be a message saying “Thanks for registering! Please log in.”.

The log in link has a class that makes it easy to select. So find it using a CSS selector, then click it. You should now be at /login.

(deftest sign-up-test
  (fetch! (app-url "/"))
  (click! (find-by-css "a.log-in"))
  (is (= (current-path) "/login")))

Let’s run that already… ok, so far so good.

(run-tests)
;; Testing booklog.acceptance-test
;;
;; Ran 1 tests containing 1 assertions.
;; 0 failures, 0 errors.

Next up click on the “Register instead” link. This one doesn’t have any special classes. You could of course add them. Sometimes people even add specific data attributes specifically for locating elements in tests.

But you can also select the link based on its link text using a bit of xpath. This is a bit more likely to break when someone tweaks the UI, but it does mean your test reflects nicely what a real user would see and do.

Now you should be on the /register page.

(deftest sign-up-test
  (fetch! (app-url "/"))
  (click! (find-by-css "a.log-in"))
  (is (= (current-path) "/login"))

  (click! (find-by-xpath "//a[text()='Register instead']"))
  (is (= (current-path) "/register")))

The form fields have individual id’s corresponding with the form parameter name. First find the #username field. Filling in form fields is done with send-text!. Now do the same for the password field. Finally locate the submit button, and click it.

If all went well you should now see the “thank you” message, which I’ll check by seeing if it occurs anywhere on the page. Writing it this way has the benefit that if the message isn’t found, the test failure shows the current page text, so you can easily see what went wrong.

(deftest sign-up-test
  (fetch! (app-url "/"))
  (click! (find-by-css "a.log-in"))
  (is (= (current-path) "/login"))

  (click! (find-by-xpath "//a[text()='Register instead']"))
  (is (= (current-path) "/register"))

  (send-text! (find-by-css "#username") "Arne")
  (send-text! (find-by-css "#password") "sekrit")
  (click! (find-by-css "input[type=submit]"))

  (is (re-find #"Thanks for registering! Please log in" (page-text))))

Next up I want to test logging in, but in order to log in you need to be registered first, meaning a user needs to exist in the database. This sign-up-test does add a user to the database, but you can’t rely on that in the next test. In fact this is a bit of a problem: this test changes the database without cleaning up after itself. The next test will now start from that new database state, so its behavior depends on what tests ran before it, which is a recipe for disaster.

You could sidestep the problem for a moment by extending this sign-up-test to also log in. It’s a valid approach, but beware of tests that do too much. Acceptance tests may look a lot like stories, but make them short stories. Instead of rambling on and on, try to get to the point and move on.

To fix the root cause I’m going to make sure the database is empty again before each test, and I’m also going to provide some helpers for loading test data into the database. How to do these things will depend a lot on the database and access library you’re using, in this case that’s MapDB and Spicerack, but regardless of what you’re using you should be able to do something similar. Have a look around, there might be libraries to help you out. I’ll link to some in the show notes.

Together with the Spicerack component you’ll find a few helper functions for dealing with the contents of the database as a single value. dump-db returns a hash-map of all data in the database, load-db! populates the database with the given data, and clear-db! makes the database all empty again.

I’ll start with the last one, clear-db!, turning it into a fixture function which empties out the databse before each test.

But first we need to be able to access the spicerack component, which is part of the system map, and this system map is currently confined to the wrap-test-system fixture.

By introducing another dynamic var you can expose it though, so helpers can use it. Inside the fixture you use binding again to assign it, just as you did with wrap-browser.

(def ^:dynamic *system* nil)

(defn wrap-test-system
  "A fixture function which sets up the system before tests and tears it down afterwards."
  [tests]
  (let [config (test-config)
        system (-> config app/app-system component/start)]
    (binding [*system* system]
      (tests))
    (component/stop system)
    (io/delete-file (:db-path config))))

Now you can write a new fixture function, wrap-clear-db which cleans out the database. It pulls the spicerack component out of the system map, and calls clear-db! on it, before running the test.

(defn wrap-clear-db
  "Test fixture which clears the database before each test."
  [test]
  (sc/clear-db! (:spicerack *system*))
  (test))

I said “test” and not “tests”, because this fixture will wrap each individual tests, rather than the whole lot of tests in a single namespace, so you use it with (use-fixtures :each ...).

With this in place there will no longer be data leaking from one test into the next.

(use-fixtures :each wrap-clear-db)

Now add two more test helpers, which wrap the dump-db and load-db! functions from Spicerack, using the current system’s spicerack component as input.

(defn dump-db []
  (sc/dump-db (:spicerack *system*)))

(defn load-db! [data]
  (sc/load-db! (:spicerack *system*) data))

The reason I’m doing all this, is that I want to write a login-test, and at the start of it I want to use load-db! to populate the database with some user data, so that I can then proceed to test logging in that user.

(deftest login-test
  (load-db! {;; ?
            })

By looking at the database at the end of the sign-up-test, I can see exactly what things look like after a person has registered, and then use that as a starting point for my next test.

Let’s run this test and watch the output, and you’ll see a hash map literal you can copy directly into your code.

(deftest sign-up-test
  ,,,
  (prn (dump-db)))

;; output:
;;
;; {"books" {},
;;  "users" {"Arne" "bcrypt+sha512$445d2014419411cd0cb8f86ecf7b9f46$12$a47115cbae94fc575ebfac0762ee2cf338876c81a8fb6af1"}}

Now you can write the login test. It sets up the state of the database, navigates to the login page, fills in and submits the form, and finally checks for the welcome message. It’s really quite similar to the sign up test.

(deftest login-test
  (load-db! {"users" {"Arne" "bcrypt+sha512$e0cf0035cd4f616d180119d2c3cd4c12$12$a841ed436714247677f0342268ede7aa9e681b71d6060b46"}})

  (fetch! (app-url "/login"))
  (send-text! (find-by-css "#username") "Arne")
  (send-text! (find-by-css "#password") "sekrit")
  (click! (find-by-css "input[type=submit]"))

  (is (re-find #"Login successful, welcome back!" (page-text))))

However, when you run the tests, this is what you get, a wall of errors. Time to investigate. Here’s your first clue: “Element not found”. Not the most informative error message ever, but it’ll have to do. You can also see that the error occured in the sign-up-test, not in the login-test. This is somewhat surprising, since it was working fine a minute ago.

Next up let’s check out that stack trace, to see exactly things went wrong. Usually the first thing to look for in a stack trace are lines relating to any of your own code. It seems like things went wrong on line 10 and line 12 of acceptance_test.clj.

Line 10 is just the deftest, but line 12 is interesting, apparently it can’t find the login link.

The reason this happened is that these two tests share the same browser instance, and the login test happened to run before the sign-up test. This means that by the time the sign-up test starts, there’s already an active session, and so the login link is no longer visible. You can see that properly isolating tests can be tricky.

It’s also worth noting that clojure.test makes no guarantees about the order in which your tests will run. This is actually a good thing, since it forces you to make sure tests don’t influence each other.

I’ll add one more fixture, this time to clear the browser’s cookies before each test.

(defn wrap-clear-cookies [test]
  (sd/delete-all-cookies! *browser)
  (test))

Add it as a fixture to run before each test.

(use-fixtures :each wrap-clear-db wrap-clear-cookies)

And finally the tests are all green.

(run-tests)
;; Testing booklog.acceptance-test
;;
;; Ran 2 tests containing 4 assertions.
;; 0 failures, 0 errors.

Before committing your code and calling it a day, remove that call to (run-tests), it’s only there for testing against a REPL, you don’t want to commit that.

(comment
  (run-tests)

Finally switch to a terminal, and run lein test. This way you’re sure they actually work, instead of accidentally due to the state your REPL is in.

And that looks good! I think we’re done here. I hope you enjoyed this episode, till next time!

$ lein test

lein test booklog.acceptance-test

lein test booklog.test-helper

Ran 2 tests containing 4 assertions.
0 failures, 0 errors.

Show Notes

browse source code

Staring point for this episode is the ep34-start branch, the final code is in the ep34-end branch.

WARNING: The Sparkledriver API is now split up into two namespaces, sparkledriver.browser and sparkledriver.element. Either stick to version 0.1.10, or adjust your namespace declarations accordingly.

Test fixture libraries

Fixpoint Clojure Test Fixtures & Datasources See also this blog post
docker-fixture Docker containers as clojure.test fixtures
Specmonstah Specmonstah lets you use the power of clojure.spec to concisely set up “the state of the world” for unit tests.
Datomock “Fork” datomic connections

These are libraries I came across in my research and seemed promising, but which I haven’t had the chance to put to real-world use. As always, apply good taste and careful judgement when picking dependencies for your projects.

Acceptance Testing With SparkleDriver