The Unofficial, official Ember Testing Guide

This was one of the sessions I was anxiously awaiting and it did not disappoint. First, a big hand of applause for Eric Berry for giving an excellent talk (his first one!). The slides were excellent and I can’t wait to continue looking into the new ember-qunit.

Testing looks at assertions. Assertions test the state of your code and QUnit is the default assertion library. In ember tests, there are always two parts, the setup and the teardown (those are callbacks). Now, there are assertions that are already provided (see the slide for those). One thing that Eric noted was that mocha and jasmine are not excluded in ember… you can use either of those for testing as well, but qunit is the happy path (a phrase I’ve come to know and love since working with ember).

Helpers help us guide our app to the state we want to test in our assertions. Looking at the callbacks, the setupForTesting sets up the router, etc. then you call injectTestHelpers which sets up the helpers so then, in your actual test, you write your helpers and then your assertions. Ember.test runs the helpers and qunit runs the assertions. Additionally, there are a bunch of different types of helpers starting with asynchronous helpers, synchronous helpers, and wait helpers. Asynchronous helpers wait for the proceeding helps to finish before they run. These are visit(), fillIn(), click(), and keyEvent(). Synchronous helpers run instantly. An example is find() and finally wait helpers wait for asynchronous helpers to complete before running. An example is andThen().

Then there are custom helpers. Use registerHelper() to create an asynchronous helper. Use registerAsyncHelper() to create a new async helper. A final reminder at the end of this part was that you still have to call injectTestHelpers to make sure you run the helpers regardless of whether they’re custom or not.

So now, the new things that will be in Ember 1.5. There will be new integration helpers. For example, triggerEvent() which takes three arguments: selector, event, and anything additional you need to add. Others are currentRouteName(), currentPath(), and currentURL().

At this point, there was an awesome example of testing search, so if you’ve got search in your app, check it out.

The next part looked at how to test in isolation. So instead of having to test all the pieces all the time, you want to test specific aspects. This is where ember-qunit was introduced. Ember-qunit is a library that lets you perform unit tests without loading the whole container. Ember-qunit was inspired by rspec. You start by setting up the globals is emq.globalize() and then you need to set up the resolver (described as the thing that can find anything… ie- mom). It also provides module helpers. These are moduleFor(), moduleForComponent(), and moduleForModel() . For the example moduleFor(“route:index”), it’s basically saying “hey resolver, I need you to pull this (the route:index in this case) from the container. moduleForModel() is specifically for testing Ember-data. There are super descriptive, awesome slides for each of these module helpers.

The last piece I noted was in controllers. In those tests, you’ll notice a “needs” field. Needs is used to bring in the dependency that the test need to bring in, in order to run… in the case on the slide, the controller for application.

To get going with ember-qunit, you just need to do bower install ember-qunit. It’s in ember-appkit and ember-cli already.

Finally, the last big announcement was that the team is redoing the testing guide on the ember.js site.

Happy Testing!!