This episode is for subscribers only. Sign Up or Log in to watch it.

34. Acceptance Testing With SparkleDriver

Published 16 August 17

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.

Show notes

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.

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