When building tools for test automation I take all the help I can get. A lot of my recent inspirations come from following what goes on in the land of Clojure, a Lisp dialect targeting the JVM.
The first thing that the Clojure people seem to be doing a lot of is generative or property-based testing. There is something exciting about tests generating failure scenarios all day, and having a fully featured QuickCheck implementation definitely helps to achieve this. To understand why this occupies my mind check out Phillip Potter’s talk on generative testing with test.check and Ashton Kemerling’s work on integration testing at Pivotal Tracker.
Some use cases we found so far at Base:
The vast majority of our integration tests are written in Ruby and this is where our business logic is modelled. That’s why Clojure’s role so far has been in peripheral tools and infrastructure.
- a proxy between RSpec integration tests and MS Exchange. We use the Java version of the Exchange Web Services library and take advantage of Clojure’s seamless interoperability with Java.
- a configuration store. Since we use RSpec as the test runner for most of our specs, we had all these config.yml files lying around that needed to be synchronised and kept up to date across our Jenkins slaves. This solution stopped scaling really fast so we decided to write a simple key-value store wrapped into a REST API.
- a fake Exchange server to test the performance of fetching contacts. We had this running in a matter of hours.
Next step: generative testing and simulation testing. It will be interesting to see how these will fit alongside our existing Gatling performance tests.
So why use this?
Judging from our couple of months of experience with the language it’s clear that it hits the spot in many ways:
- it’s running on the JVM so it has solid performance and tons of deployment options. All of our apps run on Jetty and require minimal maintenance.
- powerful language features and concise syntax
- all of Java’s ecosystem at its disposal via Java interop. This is big since Java versions tend to be reference implementations of many essential tools like Webdriver.
Of course I noticed a bit of a steeper learning curve, coming from a Ruby background. However, beyond the “fear of parens” I quickly realised that the Pareto Principle holds strong (20% of the language features cover 80% of the use-cases ;). The documentation proved to be helpful, too.
I’m pretty sure that Clojure is here to stay in my toolbelt and that you’ll hear more and more about its place in the daily lives of QAs.
Big shout out to the EuroClojure folks for last year’s conference and see you this year in Barcelona!