Wednesday, August 14, 2019

Which Clojure test runner to use?

Photo by Genaro ServĂ­n from Pexels
Clojure has a built in test framework which works very well and for most of my Clojure experience it has done the job, until yesterday.  As part of a new project I needed to integrate with Bitbucket Pipeline, specifically I needed to run my unit tests and have the build fail on a failed test and report which test failed.  Bitbucket supports this integration.

The standard way to do this is to have the test runner create a XUnit compatible XML file and have the CI tool consume this file to produce the reports.  Unfortunately, the junit.xml file created by the default Clojure test runner creates a junit.xml that does not follow the spec and Bitbucket doesn't report which tests failed.

After some research, I found that Kaocha does a much better job of creating a junit.xml that Bitbucket Pipeline can grok.  In addition, it also supports code coverage which is a great bonus.

Here is the stanza for deps.edn to make it work:

Thursday, August 8, 2019

Datomic Ions: lget does not exist


Photo by Matej from Pexels
I keep running into this exception when running Clojure in on AWS using Datomic Ions:
{ "Type": "java.lang.IllegalAccessError", "Message": "lget does not exist", "At": [ "clojure.core$refer", "invokeStatic", "core.clj", 4249 ] }
 The cause for this error seems to be that the code is trying to use either the Datomic Peer API or the wrong Datomic Client API implementation.  I am using the datomic-client-memdb for testing and if the code tries to use it on AWS, you will get that error.  Similarly, if the code tries to use the Peer library from a Datomic Ion, it will get this same error.

The problem arises from older code trying at runtime to determine if the Peer or Client API is being used.  The ways this used to be determined seem to no longer work and so the code picks the Peer when it should be the Client.

So far I have not found any code that will correctly figure out which API is being used.