Automated Solutions

Automation Engineer to the Core!

"Test Automation is the key to dependable mobile and web applications. I make it my business to have computers work for us and not the other way around."

5 Reasons Why The SDET Should Consider Using Clojure

I've been writing automated tests, and automated testing systems for 8 years now. I can honestly say without a doubt that it can be an extremely difficult feat.  I've discovered that part of the difficulty and complexity starts with the tools we've been using while developing. I've written test suites in Python, C#, Ruby and Java. Each one of these languages presented their own challenges, and at certain points made building test systems more difficult than I felt it needed to be.

One day while perusing YouTube I fumbled on to one of Rich Hickey's talks he did at the rails conference in 2012 titled "Simplicity Matters". This talk highlighted exactly how I've been feeling when it comes to writing software!! I decided to make a change and study Clojure.  While studying this language, it has literally changed the way I think about test automation as well as programming in a very fundamental way. I've listed my top 5 reasons why you should consider using this language while developing your next test suite. 


Most applications out there are moving toward a Single Page Architecture model. As you might know most of these are written entirely in Javascript. In addition to that, most major companies do most of their backend data processing in Java. If you are assigned with testing these types of systems it might make perfect sense to build your test suite and tools in Clojure. That way you can target both ecosystems during verification without having to write a single line of java or javascript! There is no more need to maintain your test suite in multiple languages if you take this approach.


I know it's said that OOP is designed for code reuse, but lately I've discovered many downfalls with the typical PAGE OBJECT MODEL. Most of these dynamic apps that I've been testing have had very interesting workflows. Suppose you have a test scenario that you must automate and it spans 8 different page objects. If you take the typical POM approach you might find yourself in a bind when you have to do multiple interactions that span many views. Clojure uses namespaces that you can use to plug and play different parts of previously existing code all throughout your code base. I've found myself surprisingly reusing  functions that I've created for entirely different purposes that I never conceived while initially authoring them. The last thing you want to be is stuck in a class based page object hierarchy.


Normally people think of test engineering as a simple pass fail dichotomy. This is no longer the case in modern systems. There are times you don't know what you're going to get when you do a specific test action,  and thus you can't limit your expectation to a hard lined pass/fail outcome. Suppose a test outcome can vary in range based on data, then what do you do?  Most of the time we test engineers deal in probable outcomes. Other times we execute tests just to gather data and understanding about our systems use by others. Clojure has a logic library that allows you to build constraints & relations as well as rules based on certain outcomes. Doing this makes your test engineering much much smarter. Remember, Quality Assurance has evolved beyond basic functional testing. We must give businesses insight on the viability of a product & its limitations in addition to verifying product requirements. 


Learning Clojure opens up a world of possibilities. It is a Lisp, and in my opinion lisp is the most powerful language construct there is. It truly stays out of your way leaving more time to focus on the problem you want to solve. Spending the time learning it opens up doors learning other lisp's as well as increasing confidence working in other language paradignms. I promise you, coding in any OOP language and going back to lisp makes you appreciate how simple lisp really is. Designing your own DSL's become much more simpler, and you are no longer held back by the limitations of a specific language. Any tool you need to create to help with testing can be built in your own DSL off of Clojure's infrastructure.  


We constantly have to share feedback about testing at most companies. Sharing these results via a web page hosted somewhere on the company intranet is really easy using HTML libraries like Hiccup. This was a pain using other ecosystems especially if you wanted to customize the presentation of your test results data. Building web reports here offers much more flexibility within the Clojure ecosystem. 

There you have it!! My top 5 reasons for using Clojure. If you never heard of it visit the Clojure Homepage   

If you want a beginner introduction check out Clojure for the brave and true.