Testing Ember Applications Dan Gebhardt @dgeb

Dan Gebhardt @dgeb

Choosing Your Tools

Decisions, decisions • Client-side test runner • In browser and headless You want to choose a test runner that supports running your tests in the browser, so you'll have access to devtools for debugging. The runner should also work headlessly, so you can test in the background as you code and be able to integrate with a CI server. The runner will need to access your compiled assets, so integration with your build environment is important.

Decisions, decisions • Client-side test runner • In browser and headless • Client-side test framework • TDD vs. BDD interfaces and assertions Popular javascript test frameworks include QUnit, Mocha, Jasmine. QUnit is used to test Ember itself, and is the most popular choice on the core team because of its speed and solid async support. Mocha is very accessible and offers custom TDD and BDD interfaces. It works with the flexible Chai assertion library. Jasmine has been extremely popular for the past few years, but seems to be slipping recently. It has awkward async support and has not seen much activity lately. It is unique in that it runs tests in parallel, while Mocha and QUnit run them serially. I've found that this can lead to non-deterministic test results with bugs that are tricky to isolate. The framework in which you write your tests will probably be the most time consuming to refactor, since every one of your tests will be written for that framework. Therefore, take some time to choose carefully.

Decisions, decisions • Client-side test runner • In browser and headless • Client-side test framework • TDD vs. BDD interfaces and assertions • Integration testing approach • Full stack vs. client-side only vs. both Full stack end-to-end tests tend to be slow to run, brittle, and redundant with testing done on both the client and server side. I'd recommend testing "happy paths" through your app rather than trying for complete coverage with E2E tests. The new ember-testing package shows promise for client-side integration tests.

No content

Many Paths to Happiness Let your environment, requirements, and preferences guide your decisions. Experiment with a few options to see which works best for you.

Rails / Konacha • Client-side test runner: • Konacha • Client-side test framework: • Mocha / Chai • Integration tests: • Capybara and/or ember-testing Konacha can run tests in the browser or headlessly with Phantomjs or Selenium drivers. Konacha runs every test in an iframe for complete separation. This is the stack Jo Liss talked about in her EmberCamp talk Konacha is opinionated: it's only compatible with Mocha Full stack end-to-end tests of your Rails application can be written in Ruby with Capybara. Capybara can run with either the selenium or phantomjs drivers. You can set breakpoints in your Capybara tests and debug in either Ruby or Firefox if needed. This is a slow process.

Grunt / Karma • Client-side test runner: • Karma • Client-side test framework: • QUnit or Mocha or Jasmine • Integration tests: • Casper.js and/or ember-testing Karma can run tests in the browser or headlessly with Phantomjs or Selenium drivers. It can even target multiple browsers and/or headless drivers at once!

Rails / Teabag • Client-side test runner: • Teabag • Client-side test framework: • QUnit or Mocha or Jasmine • Integration tests: • Capybara and/or ember-testing Like Konacha, Teabag can run tests in the browser or headlessly with Phantomjs or Selenium drivers Teabag is a relatively new test runner for Rails that appears to be flexible and promising. Caveat: I haven't tried it myself yet!

Writing Tests for Ember

Test Initialization // Prevent automatic scheduling of runloops. For tests, we // want to have complete control of runloops. Ember.testing = true; // Defer App readiness (it will be advanced in each test) App.deferReadiness(); // Prevent the router from manipulating the browser's URL. App.Router.reopen({location: 'none'});

Test Setup/Teardown beforeEach(function(done) { Ember.run(function() { App.advanceReadiness(); // Wait for the App readiness promise to resolve App.then(function() { done(); }); }); }); afterEach(function() { // Reset App state App.reset(); });

Run Loops • Prevent automatic scheduling of run loops in our tests • Instead, wrap any code with possible asynchronous side effects in run loops • Verify expectations after run loops have flushed

Object Dependencies • Understand how containers work • Lookup objects as needed from containers. You'll probably want to include some test helpers for this. • Wire together objects based upon their "needs".

Data Testing Strategies • Use fixtures for data • Load data directly into the store • Load data through an adapter • Use Sinon to mock data for your adapter • Request data from the server (for an end-to-end test)

• simple DSL for interacting with an app • visit(), click(), fillIn(), find(), wait() • handles async well Integration Tests with Ember-Testing

Ember-Testing Example test("/", function() { expect(1); visit("/").then(function() { ok(exists(".navbar"), "The navbar was rendered"); }); }); test("/posts", function() { expect(2); visit("/posts").then(function() { ok(exists('th:contains(Recent Posts)'), "Recent posts list is rendered"); ok(exists('*:contains(Please select a post)')); }); });

Testing Resources • QUnit: http://qunitjs.com • Mocha: http://visionmedia.github.io/mocha/ • Chai: http://chaijs.com/ • Konacha: https://github.com/jfirebaugh/konacha • Teabag: https://github.com/modeset/teabag • Karma: http://karma-runner.github.io • Capybara: https://github.com/jnicklas/capybara • Casper.js: http://casperjs.org/ • Sinon.js: http://sinonjs.org/

Testing Examples rails / konacha / mocha / capybara: https://github.com/dgeb/ember_data_example rails / qunit / ember-testing: https://github.com/ebryn/bloggr-client-rails forthcoming blog posts about testing: http://cerebris.com/blog

Thanks! @dgeb