The PeepCode Ordr app is an excellent video tutorial for learning Ember.js and also a great example of a browser application for writing tests in JavaScript. Learning Ember.js is a task in itself, learning to test an Ember.js comes with an equal level of challenge. This article is a collection of observations for an exercise in testing a non-trivial Ember.js application, specifically the Ordr app code from the PeepCode tutorial Fire up Ember.js video.
These comments on testing are based on a exercise with a group of hackers from the Ember-SC meetup group in Southern California. Drew, Scott, Ty and myself spent some time trying out various ways to test an Ember Application.
The journey went something like this…
* Try Jasmine because we love BDD
* Try Mocha because it’s newer and it’s used with Konacha
* Try QUnit because it may be better with async tests then the above and the Ember.js project uses it anyway
* Wow Ember.js has testing helpers in the ember-testing package, lets rewrite the integration tests
* Try Pavlov since is provides BDD style spec runner on top of QUnit
* Just use TDD QUnit test runner
In getting started with the exercise we talked and asked…
* What is important in testing an app built with Ember.js?
* Because the Ember.js framework has solid test coverage for the API it provides, is the main gap making sure an application’s compontents or modules work together?
* The underlying behavior of the framework features and API should just work, what should we not test?
* Unit tests are needed, but it would be great to have integration tests that run super fast in a JavaScript runner.
* Perhaps integration or end-to-end testing is the main objective for our exercise.
Your new post is loading...