Join our team!

We're looking for mid-level and senior software developers who love working throughout the stack, and have a track record for designing, building, shipping, and supporting web services and applications. Ideal candidates love Ruby, Rails and Ember, and using BDD and agile processes to ship working software quickly! Experience with Redis, Postgres, RabbitMQ, and ElasticSearch are a huge plus!

Follow Us

31 May 2013
by Myke Cameron

Speeding Up the Konacha JavaScript Testing Framework with Views

Konacha can only run as fast as Rails can serve it. Konacaha’s readme suggests including the JavaScript
you need to run your tests in a JavaScript spec helper, but this can result in excessively expensive asset compilation. Replacing Konacha’s iframe
view with your own implementation can yield a substantial improvement in execution time for a large test suite.

Moving to Konacha

Recently the Iora engineering team decided to start using Konacha as our JavaScript test runner after
a few of us had started using Konacha in extra-curricular projects and fallen in love with Mocha,
Chai, and the bustling Chai ecosystem. In fact, we loved Konacha so much that
we decided to forgo our usual, conservative approach to tool adoption (port it as you touch it) and instead embarked on “Chaimageddon”:
an afternoon devoted to all hands on deck porting of Jasmine tests to Chai. Chaimageddon was a big success (we migrated over half of our
very large JavaScript test suite), and pull requests full of ported tests came flooding in.

Everything looked great, until we merged…

bundle exec rake konacha:run

A few seconds pass and I decide to grab a cup of coffee; I return and it’s still running. Ten minutes later, it finishes.
Oooof. We had only ported about half of our tests and already the Konacha run was more than
twice as long as the Jasmine run had been.

Since the iframe endpoint gets hit once per spec, there was a ≈ 1500ms request for every spec file.

After profiling the iframe action in the Konacha engine the source of the sluggishness became obvious: we were requiring our spec_helper.js in
each spec file, which looked something like this (note that this spec_helper contains requires for all supporting JavaScript, as suggested in the
Konacha readme):

Since we were running these tests in the rails development environment, for each spec file, we would compile all of the assets shared across the
entire suite.

Defining a custom iframe view

When these shared assets are required through the spec helper, sprockets is forced to compile them each time, as it follows the requires from
the spec file itself, to the spec helper, and up the rest of the (potentially complex) require tree. An easy and cheap way to prevent needlessly
re-compiling these assets each time the endpoint is hit is to require them in the view itself, rather than in the spec helper. Since Konacha
is a rails engine, this is as easy as defining your own iframe.html.erb view in app/views/konacha/specs/.
We simply replaced moved all of our required JavaScript from require statements in the spec helper to the view itself, so that:

We plan on opening a pull request with a more elegant solution: require the spec_helper (or maybe konacha/manifest)
from Konacha’s iframe.html.erb if they are defined, allowing the same performance boost without requiring a monkey
patch of sorts (after all, as Konacha changes this view may change, or be eliminated entirely, leaving us in the dust!).
But for now we’re happily running fast builds and back to loving Konacha.