State of Testing in Ember 6/1/2014


#1

This is a a pared down draft of something I wrote up for my coworkers. We’re about to switch a big project over to Ember and we need to know what’s going on with testing in ember right now. Hope someone find’s this useful…

I’ve been seeing a whole bunch of different testing frameworks, syntax libraries and test runners used throughout the ember community. We’re going to have to pick just one for our big projects so I’d like to kick the discussion off on the pro’s and cons of the different options…

First some definitions:

Test Runner: runs that actually tests, will probably use phantomjs for command line running, and probably will start a server for browsers to connect to and run their own tests. Testem and Karma are test runners.

Test Framework: provides the scaffolding and functions to construct the actual tests. Mocha and Qunit are test frameworks. Can also run command line tests through nodejs or run on web pages that run in browsers.

Test Syntax: provides the style that your tests will be written in. Mocha provides a BDD style out of the box (describe, it, assert), Qunit provides a TDD style out of the box( test, equals, ok). Chai goes a step farther in the BDD style and gives you chaining syntax like Expect(foo).to.be.a(‘string’). Qunit has Qunit-bdd and Pavlov as plugins that cover some of this ground.

Research:

So it looks like ember-cli is using mocha with chai and chai-as-promised for their own internal testing. Their tests are kicked off with an npm script entry which trigger mocha, so all their tests are run on nodejs when testing is initiated from the command line. …This is contrary to the testing framework/runner that ember-cli automatically generates for new ember projects, which is a combo of qunit and testem. This seems in line with a weird pattern I’ve noticed: it seems like ember devs for the most part are using mocha to test their new libraries and projects, but emberjs is pushing qunit/testem for testing ember applications.

Here’s some stats I gathered:

Ember-cli: mocha, chai broccoli-dist-es6-module: mocha, chai EPF: mocha

Ember-cli generated Project: testem, qunit Ic-Ajax: karma, qunit Ember: qunit, rakefilebs broccolijs: jshint & tap - https://github.com/isaacs/node-tap Ember-ui: testem, qunit Ember-model: grunt, qunit

Seems like the newer projects are using mocha and the older ones are stuck with qunit.

The best thing about qunit is that ember-qunit: https://github.com/rpflorence/ember-qunit exists to make testing of ember stuff easier. The worst thing about qunit is the syntax is not as cool as the moch/chai BDD style.

There does exists some qunit plugins that give you the BDD style syntax, but they don’t work well with ember-qunit: https://github.com/square/qunit-bdd/issues/9.

There is a mocha adapter for testing ember apps (plugs into the ember testing framework), and there is some work being done to get it to the point that it can work as well as ember-qunit. As of now you can use the mocha-adapter, just without the convenience on ember-qunit. But you can still get maximal code coverage with mocha even without the convenience of ember-qunit’s helpers. There is an effort going on to get the actual ember-mocha sibling to ember-qunit written. But as of right now its just at the point of extracting the ember stuff from ember-qunit to make a generic builder file to serve as the basis for ember-qunit and ember-mocha.


#2

Perhaps consider how you will build/test components that can be shared with the community, I recently developed a micro library and based the testing / build setup off this blueprint repo and was very happy using testem, broccoli, ember-qunit and es6 modules.