Integration Testing Overview

An introduction to Mobify's integration testing practices and tools.

Run integration tests to ensure that the mobile page has been created correctly from its desktop counterpart.

To that end, integration tests involve checking that the components that you expect to appear on the mobile site are actually present there. Integration testing can be done at any time, during or after mobile site development. However, we recommend that you write the integration tests as you develop each Adaptive.js view.

A. The Differences Between an Integration Test and a System Test

System tests simulate end-to-end tests. These tests demand that the views and templates are complete and can be done towards the end stages of development.

However, this is not strictly to say that Integration Tests are only for the early stages for development. Integration tests still have value after the development is complete also. In particular, integration tests should be run during maintenance, particularly when views or templates change.

B. When to Run Integration Tests

Write tests as views are developed. Since integration tests run quickly, run them often. In particular, run the test after you make any changes to the view. Definitely test before you build a bundle.

C. Integration Testing Commands

Use one of these commands to perform your integration test. The functionality of each command is summarized by this table for your reference:

grunt test grunt test_skip_build grunt test_browser
build step x x
integration x x x
output command line command line brwoser

D. How to Write the Tests

The goal of integration testing is to ensure that the desktop page is transformed correctly to its mobile counterpart. A large part of that entails testing for expected components to appear in the adapted site.

Write your assertions in in the expect style. This style has a descriptive test name that tells us what the test is checking.

Best Practice: Use the Expect Library The expect library uses language chains that make assertions more readable. For example, expect(title)‘string’) is a self-explanatory command.

The expect language chains make assertions that read like natural language.

For example, refer to this code snippet of a context test for a pageBody element:


'context pageBody is a Zepto object': function($, context){
  var $pageBody = context.pageBody;


Best Practice: Use Descriptive Variables Choose variable names that directly describe the components that they represent.

From the previous context test code snippet, the $pageBody variable represents the page body context property. Moreover, it follows our convention where a variable for a Zepto or JQuery object is preceded by the $ symbol.

Best Practice: Test with Multiple Fixtures Test multiple page conditions with multiple fixtures in one test script.

Save fixtures for the normal state of a page, its variations, and for its exceptional cases. For example, a product description page has a normal state, a sale, and an error.

The following table contains more examples.

Normal Page Exceptional State
Product Description Sales
Empty Cart Page Cart with items
Not Logged In Logged in
Page with a Form Page with Form Errors
(missing name, email, postal code, etc...)

Best Practice: Test Global Site Features in a Separate Test Files Global includes, such as a header and a footer, have their own test files.

If the states of globally included page elements change on different templates, create a new block of tests for that file. Use fixtures that represent different states.

To test the header, use any view and a fixture that has a header. See the following HeaderTest.js code listing to understand how to implement this in your code.

function(test, view, fixture){

  test('Header context', view, fixture, {

    'context keys exist': function($, context){
      var header = context.header;, 'logo');

    'context logo anchor href': function($, context){
      var logo = context.header.logo;
      assert.equal(logo.attrs.href, 'http:///');
Edit in GitHub