Similar to the section on testing Backbone.js apps using the Jasmine BDD framework, we're nearly ready to take what we've learned and write a number of QUnit tests for our Todo application.
Before we start though, you may have noticed that QUnit doesn't support test spies. Test spies are functions which record arguments, exceptions and return values for any of their calls. They're typically used to test callbacks and how functions may be used in the application being tested. In testing frameworks, spies can usually be either anonymous functions or wrap functions which already exist.
In order for us to substitute support for spies in QUnit, we will be taking advantage of a mocking framework called SinonJS by Christian Johansen. We will also be using the SinonJS-QUnit adapter which provides seamless integration with QUnit (meaning setup is minimal). Sinon.JS is completely test-framework agnostic and should be easy to use with any testing framework, so it's ideal for our needs.
The framework supports three features we'll be taking advantage of for unit testing our application:
- Anonymous spies
- Spying on existing methods
- A rich inspection interface
Using this.spy()
without any arguments creates an anonymous spy. This is comparable to jasmine.createSpy()
and we can observe basic usage of a SinonJS spy in the following example:
test('should call all subscribers for a message exactly once', function () {
var message = getUniqueString();
var spy = this.spy();
PubSub.subscribe( message, spy );
PubSub.publishSync( message, 'Hello World' );
ok( spy.calledOnce, 'the subscriber was called once' );
});
We can also use this.spy()
to spy on existing functions (like jQuery's $.ajax
) in the example below. When spying on a function which already exists, the function behaves normally but we get access to data about its calls which can be very useful for testing purposes.
test( 'should inspect the jQuery.getJSON usage of jQuery.ajax', function () {
this.spy( jQuery, 'ajax' );
jQuery.getJSON( '/todos/completed' );
ok( jQuery.ajax.calledOnce );
equals( jQuery.ajax.getCall(0).args[0].url, '/todos/completed' );
equals( jQuery.ajax.getCall(0).args[0].dataType, 'json' );
});
SinonJS comes with a rich spy interface which allows us to test whether a spy was called with a specific argument, if it was called a specific number of times and test against the values of arguments. A complete list of features supported in the interface can be found on SinonJS.org, but let's take a look at some examples demonstrating some of the most commonly used ones:
test( 'Should call a subscriber with standard matching': function () {
var spy = sinon.spy();
PubSub.subscribe( 'message', spy );
PubSub.publishSync( 'message', { id: 45 } );
assertTrue( spy.calledWith( { id: 45 } ) );
});
Stricter argument matching: test a spy was called at least once with specific arguments and no others:
test( 'Should call a subscriber with strict matching': function () {
var spy = sinon.spy();
PubSub.subscribe( 'message', spy );
PubSub.publishSync( 'message', 'many', 'arguments' );
PubSub.publishSync( 'message', 12, 34 );
// This passes
assertTrue( spy.calledWith('many') );
// This however, fails
assertTrue( spy.calledWithExactly( 'many' ) );
});
test( 'Should call a subscriber and maintain call order': function () {
var a = sinon.spy();
var b = sinon.spy();
PubSub.subscribe( 'message', a );
PubSub.subscribe( 'event', b );
PubSub.publishSync( 'message', { id: 45 } );
PubSub.publishSync( 'event', [1, 2, 3] );
assertTrue( a.calledBefore(b) );
assertTrue( b.calledAfter(a) );
});
test( 'Should call a subscriber and check call counts', function () {
var message = getUniqueString();
var spy = this.spy();
PubSub.subscribe( message, spy );
PubSub.publishSync( message, 'some payload' );
// Passes if spy was called once and only once.
ok( spy.calledOnce ); // calledTwice and calledThrice are also supported
// The number of recorded calls.
equal( spy.callCount, 1 );
// Directly checking the arguments of the call
equals( spy.getCall(0).args[0], message );
});
SinonJS also supports two other powerful features which aer useful to be aware of: stubs and mocks. Both stubs and mocks implement all of the features of the spy API, but have some added functionality.
A stub allows us to replace any existing behaviour for a specific method with something else. They can be very useful for simulating exceptions and are most often used to write test cases when certain dependencies of your code-base may not yet be written.
Let us briefly re-explore our Backbone Todo application, which contained a Todo model and a TodoList collection. For the purpose of this walkthrough, we want to isolate our TodoList collection and fake the Todo model to test how adding new models might behave.
We can pretend that the models have yet to be written just to demonstrate how stubbing might be carried out. A shell collection just containing a reference to the model to be used might look like this:
var TodoList = Backbone.Collection.extend({
model: Todo
});
// Let's assume our instance of this collection is
this.todoList;
Assuming our collection is instantiating new models itself, it's necessary for us to stub the model's constructor function for the the test. This can be done by creating a simple stub as follows:
this.todoStub = sinon.stub( window, 'Todo' );
The above creates a stub of the Todo method on the window object. When stubbing a persistent object, it's necessary to restore it to its original state. This can be done in a teardown()
as follows:
this.todoStub.restore();
After this, we need to alter what the constructor returns, which can be efficiently done using a plain Backbone.Model
constructor. Whilst this isn't a Todo model, it does still provide us an actual Backbone model.
setup: function() {
this.model = new Backbone.Model({
id: 2,
title: 'Hello world'
});
this.todoStub.returns( this.model );
});
The expectation here might be that this snippet would ensure our TodoList collection always instantiates a stubbed Todo model, but because a reference to the model in the collection is already present, we need to reset the model property of our collection as follows:
this.todoList.model = Todo;
The result of this is that when our TodoList collection instantiates new Todo models, it will return our plain Backbone model instance as desired. This allows us to write a spec for testing the addition of new model literals as follows:
module( 'Should function when instantiated with model literals', {
setup:function() {
this.todoStub = sinon.stub(window, 'Todo');
this.model = new Backbone.Model({
id: 2,
title: 'Hello world'
});
this.todoStub.returns(this.model);
this.todos = new TodoList();
// Let's reset the relationship to use a stub
this.todos.model = Todo;
this.todos.add({
id: 2,
title: 'Hello world'
});
},
teardown: function() {
this.todoStub.restore();
}
});
test('should add a model', function() {
equal( this.todos.length, 1 );
});
test('should find a model by id', function() {
equal( this.todos.get(5).get('id'), 5 );
});
});
Mocks are effectively the same as stubs, however they mock a complete API out and have some built-in expectations for how they should be used. The difference between a mock and a spy is that as the expectations for their use are pre-defined, it will fail if any of these are not met.
Here's a snippet with sample usage of a mock based on PubSubJS. Here, we have a clearTodo()
method as a callback and use mocks to verify its behavior.
test('should call all subscribers when exceptions', function () {
var myAPI = { clearTodo: function () {} };
var spy = this.spy();
var mock = this.mock( myAPI );
mock.expects( 'clearTodo' ).once().throws();
PubSub.subscribe( 'message', myAPI.clearTodo );
PubSub.subscribe( 'message', spy );
PubSub.publishSync( 'message', undefined );
mock.verify();
ok( spy.calledOnce );
});
We can now begin writing test specs for our Todo application, which are listed and separated by component (e.g Models, Collections etc.). It's useful to pay attention to the name of the test, the logic being tested and most importantly the assertions being made as this will give you some insight into how what we've learned can be applied to a complete application.
To get the most out of this section, I recommend looking at the QUnit Koans included in the practicals/qunit-koans
folder - this is a port of the Backbone.js Jasmine Koans over to QUnit.
In case you haven't had a chance to try out one of the Koans kits as yet, they are a set of unit tests using a specific testing framework that both demonstrate how a set of specs for an application may be written, but also leave some tests unfilled so that you can complete them as an exercise.
For our models we want to at minimum test that:
- New instances can be created with the expected default values
- Attributes can be set and retrieved correctly
- Changes to state correctly fire off custom events where needed
- Validation rules are correctly enforced
module( 'About Backbone.Model');
test('Can be created with default values for its attributes.', function() {
expect( 1 );
var todo = new Todo();
equal( todo.get('text'), '' );
});
test('Will set attributes on the model instance when created.', function() {
expect( 3 );
var todo = new Todo( { text: 'Get oil change for car.' } );
equal( todo.get('text'), 'Get oil change for car.' );
equal( todo.get('done'), false );
equal( todo.get('order'), 0 );
});
test('Will call a custom initialize function on the model instance when created.', function() {
expect( 1 );
var toot = new Todo({ text: 'Stop monkeys from throwing their own crap!' });
equal( toot.get('text'), 'Stop monkeys from throwing their own rainbows!' );
});
test('Fires a custom event when the state changes.', function() {
expect( 1 );
var spy = this.spy();
var todo = new Todo();
todo.on( 'change', spy );
// How would you update a property on the todo here?
// Hint: http://documentcloud.github.com/backbone/#Model-set
todo.set( { text: 'new text' } );
ok( spy.calledOnce, 'A change event callback was correctly triggered' );
});
test('Can contain custom validation rules, and will trigger an error event on failed validation.', function() {
expect( 3 );
var errorCallback = this.spy();
var todo = new Todo();
todo.on('error', errorCallback);
// What would you need to set on the todo properties to cause validation to fail?
todo.set( { done: 'not a boolean' } );
ok( errorCallback.called, 'A failed validation correctly triggered an error' );
notEqual( errorCallback.getCall(0), undefined );
equal( errorCallback.getCall(0).args[1], 'Todo.done must be a boolean value.' );
});
For our collection we'll want to test that:
- New model instances can be added as both objects and arrays
- Changes to models result in any necessary custom events being fired
- A
url
property for defining the URL structure for models is correctly defined
module( 'About Backbone.Collection');
test( 'Can add Model instances as objects and arrays.', function() {
expect( 3 );
var todos = new TodoList();
equal( todos.length, 0 );
todos.add( { text: 'Clean the kitchen' } );
equal( todos.length, 1 );
todos.add([
{ text: 'Do the laundry', done: true },
{ text: 'Go to the gym' }
]);
equal( todos.length, 3 );
});
test( 'Can have a url property to define the basic url structure for all contained models.', function() {
expect( 1 );
var todos = new TodoList();
equal( todos.url, '/todos/' );
});
test('Fires custom named events when the models change.', function() {
expect(2);
var todos = new TodoList();
var addModelCallback = this.spy();
var removeModelCallback = this.spy();
todos.on( 'add', addModelCallback );
todos.on( 'remove', removeModelCallback );
// How would you get the 'add' event to trigger?
todos.add( {text:'New todo'} );
ok( addModelCallback.called );
// How would you get the 'remove' callback to trigger?
todos.remove( todos.last() );
ok( removeModelCallback.called );
});
For our views we want to ensure:
- They are being correctly tied to a DOM element when created
- They can render, after which the DOM representation of the view should be visible
- They support wiring up view methods to DOM elements
One could also take this further and test that user interactions with the view correctly result in any models that need to be changed being updated correctly.
module( 'About Backbone.View', {
setup: function() {
$('body').append('<ul id="todoList"></ul>');
this.todoView = new TodoView({ model: new Todo() });
},
teardown: function() {
this.todoView.remove();
$('#todoList').remove();
}
});
test('Should be tied to a DOM element when created, based off the property provided.', function() {
expect( 1 );
equal( this.todoView.el.tagName.toLowerCase(), 'li' );
});
test('Is backed by a model instance, which provides the data.', function() {
expect( 2 );
notEqual( this.todoView.model, undefined );
equal( this.todoView.model.get('done'), false );
});
test('Can render, after which the DOM representation of the view will be visible.', function() {
this.todoView.render();
// Hint: render() just builds the DOM representation of the view, but doesn't insert it into the DOM.
// How would you append it to the ul#todoList?
// How do you access the view's DOM representation?
//
// Hint: http://documentcloud.github.com/backbone/#View-el
$('ul#todoList').append(this.todoView.el);
equal($('#todoList').find('li').length, 1);
});
asyncTest('Can wire up view methods to DOM elements.', function() {
expect( 2 );
var viewElt;
$('#todoList').append( this.todoView.render().el );
setTimeout(function() {
viewElt = $('#todoList li input.check').filter(':first');
equal(viewElt.length > 0, true);
// Make sure that QUnit knows we can continue
start();
}, 1000, 'Expected DOM Elt to exist');
// Hint: How would you trigger the view, via a DOM Event, to toggle the 'done' status.
// (See todos.js line 70, where the events hash is defined.)
//
// Hint: http://api.jquery.com/click
$('#todoList li input.check').click();
expect( this.todoView.model.get('done'), true );
});
For events, we may want to test a few different use cases:
- Extending plain objects to support custom events
- Binding and triggering custom events on objects
- Passing along arguments to callbacks when events are triggered
- Binding a passed context to an event callback
- Removing custom events
and a few others that will be detailed in our module below:
module( 'About Backbone.Events', {
setup: function() {
this.obj = {};
_.extend( this.obj, Backbone.Events );
this.obj.off(); // remove all custom events before each spec is run.
}
});
test('Can extend JavaScript objects to support custom events.', function() {
expect(3);
var basicObject = {};
// How would you give basicObject these functions?
// Hint: http://documentcloud.github.com/backbone/#Events
_.extend( basicObject, Backbone.Events );
equal( typeof basicObject.on, 'function' );
equal( typeof basicObject.off, 'function' );
equal( typeof basicObject.trigger, 'function' );
});
test('Allows us to bind and trigger custom named events on an object.', function() {
expect( 1 );
var callback = this.spy();
this.obj.on( 'basic event', callback );
this.obj.trigger( 'basic event' );
// How would you cause the callback for this custom event to be called?
ok( callback.called );
});
test('Also passes along any arguments to the callback when an event is triggered.', function() {
expect( 1 );
var passedArgs = [];
this.obj.on('some event', function() {
for (var i = 0; i < arguments.length; i++) {
passedArgs.push( arguments[i] );
}
});
this.obj.trigger( 'some event', 'arg1', 'arg2' );
deepEqual( passedArgs, ['arg1', 'arg2'] );
});
test('Can also bind the passed context to the event callback.', function() {
expect( 1 );
var foo = { color: 'blue' };
var changeColor = function() {
this.color = 'red';
};
// How would you get 'this.color' to refer to 'foo' in the changeColor function?
this.obj.on( 'an event', changeColor, foo );
this.obj.trigger( 'an event' );
equal( foo.color, 'red' );
});
test( 'Uses `all` as a special event name to capture all events bound to the object.', function() {
expect( 2 );
var callback = this.spy();
this.obj.on( 'all', callback );
this.obj.trigger( 'custom event 1' );
this.obj.trigger( 'custom event 2' );
equal( callback.callCount, 2 );
equal( callback.getCall(0).args[0], 'custom event 1' );
});
test('Also can remove custom events from objects.', function() {
expect( 5 );
var spy1 = this.spy();
var spy2 = this.spy();
var spy3 = this.spy();
this.obj.on( 'foo', spy1 );
this.obj.on( 'bar', spy1 );
this.obj.on( 'foo', spy2 );
this.obj.on( 'foo', spy3 );
// How do you unbind just a single callback for the event?
this.obj.off( 'foo', spy1 );
this.obj.trigger( 'foo' );
ok( spy2.called );
// How do you unbind all callbacks tied to the event with a single method
this.obj.off( 'foo' );
this.obj.trigger( 'foo' );
ok( spy2.callCount, 1 );
ok( spy2.calledOnce, 'Spy 2 called once' );
ok( spy3.calledOnce, 'Spy 3 called once' );
// How do you unbind all callbacks and events tied to the object with a single method?
this.obj.off( 'bar' );
this.obj.trigger( 'bar' );
equal( spy1.callCount, 0 );
});
It can also be useful to write specs for any application bootstrap you may have in place. For the following module, our setup initiates and appends a TodoApp view and we can test anything from local instances of views being correctly defined to application interactions correctly resulting in changes to instances of local collections.
module( 'About Backbone Applications' , {
setup: function() {
Backbone.localStorageDB = new Store('testTodos');
$('#qunit-fixture').append('<div id="app"></div>');
this.App = new TodoApp({ appendTo: $('#app') });
},
teardown: function() {
this.App.todos.reset();
$('#app').remove();
}
});
test('Should bootstrap the application by initializing the Collection.', function() {
expect( 2 );
notEqual( this.App.todos, undefined );
equal( this.App.todos.length, 0 );
});
test( 'Should bind Collection events to View creation.' , function() {
$('#new-todo').val( 'Foo' );
$('#new-todo').trigger(new $.Event( 'keypress', { keyCode: 13 } ));
equal( this.App.todos.length, 1 );
});
That's it for this section on testing applications with QUnit and SinonJS. I encourage you to try out the QUnit Backbone.js Koans and see if you can extend some of the examples. For further reading consider looking at some of the additional resources below: