- It’s very fast.
- It comes with support for the Rails asset pipeline. 
- It supports CoffeeScript.
- You can use the in-browser runner (good for development), or run your test suite from the command line through Selenium (good for build servers).
What it cannot do is talk to the server. In particular:
- It cannot use the database.
- It cannot access your Rails (server-side) views. Any DOM nodes you are testing need to be created on the client side (for instance with JST templates), not served out by views.
When you need either of these two, write integration tests with Capybara instead.
1 2 3 4 5 6 7 8
To test this, first add Konacha to your Gemfile:
1 2 3
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
We’ll get to the details of the syntax in a minute.
If you prefer CoffeeScript, you can also use
.js.coffee spec files. For spec
files in particular, I find CoffeeScript much more readable than plain
bundle exec rake konacha:serve, and point your browser at
If everything loaded alright, you should now see two tests passing, and the third one failing:
Testing the DOM
Let’s write up a minimal three-line app:
1 2 3 4 5
appendTo shall be the method used to initialize our app and render it
into the DOM – normally into an empty root div provided by the view. To test
it with Konacha, we render it into the special
#konacha div, which is
automatically cleared between test cases.
1 2 3 4 5 6 7 8 9 10 11 12
The assertions you saw in the test code above –
assert.ok(...) – are provided through the Chai testing library. Chai comes
with two assertion styles, which you can mix and match freely in your tests:
should/expect (“BDD-style”) and
I generally find the
should style more readable, but I recommend you still
acquaint yourself with both styles, as they are not one-to-one equivalents.
If you are coming from RSpec, you will be disappointed to find that Chai’s
should interface is much less powerful than RSpec’s. For example, it does not
allow you to call arbitrary
So whereas in Ruby I would write
1 2 3 4 5 6 7 8
Extract common code into a
//= require spec_helperat the top of each spec file.
Group your tests into subdirectories as you see fit.
It’s happened to me several times that I wrote assertions that cannot fail. Examples include
.should.be.thisIsATypo(does nothing) and
emptydoes not play with jQuery). For that reason, I recommend practicing test-first development, so you’ve seen each of your tests fail at least once.
Writing DOM tests with jQuery turns out to be rather awkward. Try adding chai-jquery to your project for some jQuery-specific Chai assertions. For instance:
 Without asset pipeline support, you would either have to enumerate all your
dependencies manually, or include the generated
application.js file and live
with stack-traces like
Thanks to John Firebaugh, Yuri Gadow, and Joel Parker Henderson for reading drafts of this.