- It’s very fast.
still trigger events, e.g. with jQuery, if you need to simulate user actions.
- 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
want to test the following function in a Rails 3.1+ app:
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:
open in the Konacha browser window, so you can see errors. If there are any
issues with loading your tests (such as syntax errors in your test
declarations), Konacha will not catch it and display an error. You just get a
blank test page, or worse, parts of your test suite are silently dropped. For
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
//=at 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.
.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.
Read more at the source