Test-driven Development of a Backbone.js App. Part 2.


Please note that you will find all 3 parts of this article as well as the source code of the tutorial in the project’s GitHub repository.


Implementing Backbone.js Model

In the first part of the series I walked you through the test-driven development concepts. Then we have set up the project workspace, including a QUnit test runner and an empty source files accompanied with test files.

In the second part of the article, we will create our first Backbone.js model using TDD principles.

Early on in the project I decided to use the Backbone.js library and build our ControlColor component on top of it. In this case, first, we have to make sure that we’re dealing with a Backbone model.

To do so, we can look into object’s prototype and search for e.g. fetch and sync methods, which are pretty specific to Backbone models:

QUnit.module( 'models/control-color.js', function() {
  QUnit.test( 'Color control exists and is Backbone model', function( assert ) {
     var Model = window.ControlColor;

     assert.ok( ! _.isUndefined( Model ), 'model is defined' );
     assert.ok( _.isFunction( Model.prototype.fetch ) && _.isFunction( Model.prototype.sync ), 'model is Backbone model' );
  } );
} );

If we run unit tests now (refresh the browser), we will get one failing test:

Tests completed in 10 milliseconds.
1 assertions of 2 passed, 1 failed.

To fix it, we have to make ControlColor a real Backbone model:

window.ControlColor = Backbone.Model.extend( {} );

Now both tests are passing, so we have successfully gone through the green phase. There is nothing to refactor at this point, so we’re skipping this step.

Our new Backbone model has to store an array of available options and an array of currently selected options. So let’s write some tests to describe those requirements:

QUnit.module( 'models/control-color.js', function() {
  ...
  QUnit.test( 'Model has required properties', function( assert ) {
    var model = new window.ControlColor();

    assert.ok( model.has( 'options' ), 'model has "options" property' );
    assert.ok( _.isArray( model.get( 'options' ) ), '"options" is array' );

    assert.ok( model.has( 'checked' ), 'model has "checked" options property' );
    assert.ok( _.isArray( model.get( 'checked' ) ), '"checked" options is array' );
  } );
} );

All 4 tests are failing, so we’re good to proceed to green phase. Note that in this set of tests, we’ve already initialized the ControlColor model so that we can use Backbone methods like has() or get().

To make tests pass, let’s define defaults property in the ControlColor model:

window.ControlColor = Backbone.Model.extend( {
  defaults: {
     options: [],
     checked: []
  }
} );

Tests are green now. Again we won’t refactor neither implementation nor testing code.

Continue reading Test-driven Development of a Backbone.js App. Part 2.

Integrating AMP into WordPress: A Comprehensive Guide

AMP is an emerging technology that’s gaining the attention of online marketers in all fields.  It formats content in a way that loads blazingly fast for mobile visitors, whose page load time expectations can be as little as three seconds. I recently worked with a client who wanted to improve their page load times by … Continue reading Integrating AMP into WordPress: A Comprehensive Guide

Test-driven Development of a Backbone.js App. Part 1.


Please note that you will find all 3 parts of this article as well as the source code of the tutorial in the project’s GitHub repository.


Implementing test-driven development (TDD) principles based on a QUnit testing suite.

In one of the projects I worked on recently, there was a requirement to accompany our JavaScript code with unit tests. That is when I thought to myself that it would be a good idea to give test-driven development a try. But right then, a voice in my head said:

Nah! Writing unit tests first having no implementation seems unreasonable. Plus – in TDD I have to write unit tests for each and every module, not only the crucial ones. This means more code, and more time needed.

Luckily, at the time I stumbled upon an excellent series of articles by James Sinclair (for me a must-read for anyone wanting to step into TDD). The author shows test-driven development in a very interesting way. James Sinclair states that in TDD the programmer is more confident in his code while the development process is both efficient and enjoyable to the coder!

How is it so? Boring unit testing being fun to the developer? Now I just had to give TDD a try!

TDD Fundamentals

As you probably already know from James Sinclair’s post, each step in test-driven development is split into 3 phases:

  1. Red – write always-failing test.
  2. Green – write the simplest-possible implementation for the failing test.
  3. Refactor – rewrite implementation code in order to optimise and simplify the solution.

Always start with writing a failing test in the red phase. It will prevent your unit test from being erroneous (e.g. having always-passing test or trying to implement functionality that is already there).

Then write the simplest solution (even if it seems dumb) in green phase. Your aim is to write code that just passes the test. This way your implementation will stay lean, without any unnecessary code left here and there “just in case”.

Having the green light, you should go back to the implementation and refactor each snippet you feel could be written better. Please keep in mind your testing code is nothing you should be ashamed of. It deserves refactoring too!

Everything seems to be working well now? Rinse and repeat those 3 steps until you feel all requirements are satisfied for that particular module.

Sounds fairly simple? Let’s try to illustrate the process with an example then.

Continue reading Test-driven Development of a Backbone.js App. Part 1.

Image Gallery Control for the Customizer

The Customize Image Gallery Control plugin adds a new control type to the customizer: image_gallery. This control populates its associated setting with an array of the selected image (attachment) IDs. What’s Image Gallery Control good for? Currently the customizer provides media controls that only allow one image to be selected. If multiple images are needed, each … Continue reading Image Gallery Control for the Customizer

Dependently-Contextual Customizer Controls

In my previous post I discussed how to get the Customizer preview to navigate to a URL when a section is expanded, where this is basically turning the concept of contextual controls on its head: instead of showing a control/section/panel when navigating to a given URL, focusing on the control/section/panel can cause the relevant URL to be … Continue reading Dependently-Contextual Customizer Controls

Navigating to a URL in the Customizer Preview when a Section is Expanded

On Otto’s What’s new with the Customizer post there’s a long-running comments thread in which a good question was raised by Jascha: with the active callback you can show a section or panel depending on the URL you are looking at. But is it possible the other way around? Showing a different URL depending on … Continue reading Navigating to a URL in the Customizer Preview when a Section is Expanded

Customizer Browser History Plugin

I’m happy to share a newly published feature plugin that implements #28536: Customizer Browser History. From the readme: This plugin keeps the Customizer URL in the browser updated with current previewed URL as the url query param and current expanded panel/section/control as autofocus params. This allows for bookmarking and also the ability to reload and return go … Continue reading Customizer Browser History Plugin

Matt Mullenweg on the Customizer in WP Tavern Interview

Matt Mullenweg, co-founder of WordPress, was recently interviewed on WP Tavern. He had some important things to say about the Customizer at 1:05:00 into the interview (transcript below): Jeff Chandler: At WordCamp US you said that Customization is the single biggest opportunity for improving the WordPress experience, and I wanted to know, could you expand … Continue reading Matt Mullenweg on the Customizer in WP Tavern Interview

Registering Project-specific PHP_CodeSniffer Rulesets in PhpStorm

In wp-dev-lib we have followed a convention of naming our project-specific PHP_CodeSniffer rulesets as phpcs.ruleset.xml. We named the ruleset files with “phpcs” in the filename to make it clear what kind of ruleset it is, and so that it would conflict with any other tool that may also want to use this name. Nevertheless, PHP_CodeSniffer … Continue reading Registering Project-specific PHP_CodeSniffer Rulesets in PhpStorm