Menu

Integration Testing Best Practices

Grunt Test Commands Read about the Grunt commands used to run tests in our Integration Testing Overview.


Best Practice: Test as you Develop Write tests as views are developed. Write tests once your context properties are defined to ensure that the desktop page is transformed correctly to the mobile version.


Best Practice: Run Tests Often Integration tests are designed to run quickly which encourages you to run them often. At minimum, run tests before you build a bundle.


Best Practice: One Assertion Per Test Limit the number of assertions to 1 per test, or to 1 property per test.

The benefit of this is that the test executes faster in your browser and is easier to debug. It is also neater. If the test fails, you know exactly what it failed on.


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

Tests written with expect and assert achieve similar effects. For an assertion written with assert, there is generally an equivalent assertion written in expect and vice versa. Both take an arbitrary debug message that is output when the assertion fails.

Assert vs. Expect: Check Equality

With assert:

'context logo anchor href': function($, context){
      var logo = context.header.logo;

      assert.equal(logo.attrs.href, 'http://www.jtv.com/homepage');
}

The assert style command takes two arguments, whose order is not necessarily intuitive.

With expect:

'context logo anchor href': function($, context){
  var logo = context.header.logo;

  expect(logo.attrs.href).to.equal('http://www.jtv.com/homepage');
}

The expect style command also takes the same two arguments. However, the linguistic structure of the command makes the order of the arguments more obvious. The test is also clearly labeled as an equality test.

Assert vs. Expect: Check Type

With assert:

'context.footerContact is an object': function($, context){
  assert.isObject(context.footer.footerContact);
}

With expect:

'context.footerContact is an object': function($, context){
  expect(context.footer.footerContact).to.be.a('object');
}

Assert vs. Expect: Check for Elements Present

With assert:

'shippingBanner returns Zepto object': function($, context){
  assert.elementsPresent(context.header.shippingBanner);
}

With expect:

'shippingBanner returns Zepto object': function($, context){
  expect(context.header.shippingBanner).to.have.elementsPresent();
}

Assert vs. Expect: Check Properties

With assert:

'context contains expected properties': function($, context){
  assert.property(context, 'content');
  assert.property(context, 'title');
  assert.property(context, 'intro');
}

The assert style command tests each property of the context in a separate command per each property.

With expect:

'context contains expected properties': function($, context){
  expect(context).to.have.properties('content', 'title', 'intro');
}

The expect style command takes in all of the properties as a list.

Assert vs. Expect: Check Property Value

With assert:

'context ERV Price returns a string': function($, context) {
    var priceComparison = context.priceComparison;
    assert.property(priceComparison, 'erv');
    assert.equal(priceComparison.erv, 'ERV: $336.00');
}

The assert commands tests separately for the property and then for the property's equality to a particular value.

With expect:

'context ERV Price returns a string': function($, context) {
    var priceComparison = context.priceComparison;
    expect(priceComparison).to.have.property('erv', 'ERV: $336.00');
}

The expect style command tests for the property and the property's value in one line.

Custom Chai Assertions Refer to our Custom Chai Assertions API for custom commands in the expect style for testing Mobify sites.


Best Practice: Use Descriptive Test Names The test name outputs to the console and makes it easy which component or property fails.

An example of a descriptive test name is context.shipping property contains the expected string.


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

For example, the var menuItem = context.menuItem; assignment clearly assigns the menu item to a variable by the same name.

Best Practice: Use the $ Prefix By convention, preface variables that represent a Zepto or a jQuery object with a $ character.

For example:

var $body = $('body');

Best Practice: Write Tests that are Sufficient Use your own discretion. Test for expected types, values, and lengths of your context properties.

Examples of expected types: Object, String, Array, etc. Test for equality to expected value. With the expected value, test for equality, greater or less than.


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


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 states change on different templates (like a different header for the checkout page), create a new block of tests for that file. Use fixtures that represent different states.

Edit in GitHub