Running Elm Test in Atom: The Making of “Elm Test Runner”

Years ago, early in my software engineering career, I entered a new workplace and had unknowingly dropped into the middle of a cold war. Some months prior, an engineering manager had instituted a policy of test-driven development. One group of engineers had embraced the practice, while another had become radically opposed. I struggled to figure out what I believed amidst the polarized opinions around me.

Months later, I managed to extract myself to another group and thus away from the conflict. Shortly after joining, I was asked to build out a large front-end JavaScript system. This was a time before either Angular or React. My only libraries were jQuery and Underscore for the application, and Jasmine for testing. I found myself at first falling back on old and comfortable habits of non-testing; I attempted to leave the cold war behind me by ignoring testing altogether.

But JavaScript, as many engineers know, is ruthless. I watched my designs decompose before my eyes to a glueball that felt all-too-familar, and I knew what the TDDers would surely be saying about what I was doing. I had to admit that my approach wouldn’t scale, and that I would have to embrace testing if the project was to succeed. I also didn’t want to end up with the many brittle, fragile tests that the anti-TDD group loved to point out in order to justify their claims. I decided I would need to build the right tests.

The results surpassed my wildest expectations. Within a month of deciding to adopt a test-driven approach (while also maintaining careful attention to architecture and organization), I was able to clean up my glueball into something good, perhaps even approaching elegant. It was a codebase that other engineers, after I moved on to another project, were able to pick up quickly and continue to develop.

From that point on in my career, I have been passionate about finding the best testing strategy for my projects, both in the workplace and outside it.

When I first came to the Elm programming language, I was impressed by the fact that a language so young already possessed a robust unit testing framework in the form of Elm Test. After I got through the language basics, I progressed quickly into developing my testing strategy for Elm applications.

As I used Elm Test more and more, I couldn’t help but notice a bit of friction that I wasn’t used to. Namely, I had to command-tab back and forth between Atom and my terminal in order to run my tests. This was far different from the situation I had grown used to during years of PHP, Java, and C# development, where tests can be run inside one’s editor at the stroke of a command key.

And so, I decided to build such a tool. Elm Test Runner searches your project for an Elm directory with tests and executes Elm Test on that directory in a background process. It then parses the Elm Test output into a tree structure and will display any error output, if present. I also included tools for copying out the run seed, and forcing it to a particular value, all within the editor.

I learned a ton about Elm building Elm Test Runner. I got to apply and develop many of the principles I discussed in my article, “High-Level Dependency Strategies in Elm.” I used ports and JSON decoders for the first time. And finally, I built up a working knowledge about how to create an Atom plugin primarily in Elm. Elm Test Runner is, naturally, an Elm application with the minimum possible amount of JavaScript glue tying it into Atom.

Most of all, Elm Test Runner was fun to create, and I look forward to continuing to expand its functionality.

You can install Elm Test Runner by searching for “elm-test-runner” in Atom. You can also find the project source code on GitHub.