Changes associated with Jasmine 2.4

Key Benefits

Architectural Changes

    Core Files

  • To review, the core files for Jasmine are stored in WebTier/qbo.ApplicationWeb/Templates/Spec
  • Jasmine 2.4 is comprised of the following core files:
    • boot.js
    • console.js
    • jasmine-html.js
    • jasmine.css
    • jasmine.js
    • jasmine_favicon.png
  • In addition, because of limited extensibility, we now have a file for QBO customization called:
    • jasmine_qbo.js

    2.4 Architectural Overview

  • The Jasmine instance is now created by the boot.js file.
  • As before, the core logic of Jasmine is in jasmine.js (or jasmine_qbo.js for QBO)
  • Rendering of reports is handled in jasmine-html.js

    QBO Customization in Core Files

        Registering custom matchers

            Previously, we registered custom matchers in qbo.SpecHelpers.js with the following pattern:
            jasmine.Matchers.prototype.toHave* = function(expected){ *compare actual vs expected and return result*}

            As of Jasmine 2.0, the custom matchers are now hidden via closure, and the jasmine.Matchers.prototype is no longer accessible.

            The recommended method of adding custom matchers is the new jasmine.addMatchers() function, as documented here: 

            The problem is that there is no way to globally addMatchers one time, and then be done. As noted in the documention, Jasmine directs users to place any                        addMatchers() call in a beforeEach() function. This would require us to place a global dependency in each instance of a qbo spec test, which leads to duplication             and superflous code

            For the time being, my solution is not elegant, but it works. As we previously registers custom matchers in qbo.SpecHelpers.js, I am now registering them in                jasmine_qbo.js.

            The first step is to add the names of our custom matchers to the array of custom matcher names at the top of the file:    

        Step two is to register the respective custom matchers with the following pattern
         getJasmineRequireObj().customMatcherName= function () {
        function customMatcherName() {
             return {
             compare: function (actual, additionalParam) {
                 return {
                     pass: *compare actual vs expected*
             return customMatcherName;

        Here is a concrete example:


ASync Support

Previously, Jasmine employed runs()/waitsFor() blocks to allow for timing during tests.

The new pattern employees a done() method.

In order to implement async support, there must be a beforeEach() method that initializes the behavior:
    beforeEach(function (done) {
    setTimeout(function () {
       value = 0;
        }, 1000);
        There must also be an afterEach() method:
    afterEach(function (done) {
    }, 1000);
        The spec that should utilize timing then follows this pattern:
    it('can fetch data via AJAX', function (done) {

Changes in Specification Design

QBO Spec Helper Functions