Running RequireJS unit tests

As of version 3.0 Chutzpah has specialized support for running tests using RequireJS. Below are two simple examples, for more complex examples which demonstrate Mocha, Jasmine, Qunit and TypeScript please check out the [Samples folder|https://github.com/mmanela/chutzpah/tree/master/Samples/] in the source tree.

RequireJS with QUnit using JavaScript

In this sample there is a RequireJS module in the base folder and a test file in the tests/base folder. Below I show the file structure of the sample and the source of the test file and the code file tests.

File Structure

chutzpah.json
require-2.1.8.js 
 
base/
  core.js 
 
tests/
  base/
    base.qunit.test.js

core.js

define(function () {
    return {
        version: 8
    };
});

base.qunit.test.js

define(['base/core'],
    function (core) {
        module("base/core");
        test("will return correct version from core", function () {
            var version = core.version;
            equal(version, 8);
        });
    });

The key to being able to run the base.qunit.test.js test file is to set up the chutzpah.json file. This sample uses the following chutzah.json file:

{
    "Framework": "qunit",
    "TestHarnessReferenceMode": "AMD",
    "TestHarnessLocationMode": "SettingsFileAdjacent",
    "References" : [
        {"Path" : "require-2.1.8.js" } 
    ]
}

The chutzpah.json file is making use of a few new settings in version 3.0. Setting TestHarnessReferenceMode to AMD tells Chutzpah that we are running tests that use the AMD style. In this mode Chutzpah will not insert references (discovered from ///<reference comments and the test file into the test harness. Instead it will inject a require statement in the test harness with the right path to the file under test. I then list explicitly which references I want injected into the test harness (in this case just require.js). The settings file should be place at the root of your AMD project (i.e. where you want all your paths relative to) and you should set the TestHarnessLocationMode to be SettingsFileAdjacent which places the generated harness in the same folder.

With this setup you can run chutzpah as follows:

chutzpah.console.exe tests\base\base.qunit.test.js

RequireJS with QUnit using TypeScript

This is the same example as above expect with everything converted to TypeScript. To be able run this example there are a couple extra settings in the Chutzpah.json file.

File Structure

chutzpah.json
require-2.1.8.js
require.d.ts
qunit.d.ts 
 
base/
  core.ts 
 
tests/
  base/
    base.qunit.test.ts 

out/
  *compiled files are put here*

core.ts

export var version = 8;

base.qunit.test.ts

import core = require('base/core');
 
QUnit.module("base/core");
test("will return correct version from core", function () {
    var version = core.version;
    equal(version, 8);
});

The TypeScript versions of these files make use of TypeScript’s nice import/require syntax which make its cleaner to write code in the AMD style.

The chutzpah.json file needed to run this sample is:

{
   "Framework": "qunit",
   "TestHarnessReferenceMode": "AMD",
   "TestHarnessLocationMode": "SettingsFileAdjacent",   
   "AMDBaseUrl": "out",
   "AMDAppDirectory": "./",
   "References" : [
      { "Path": "require-2.1.8.js" }
    ],
    "Compile": {
      "Mode": "External",
      "Extensions": [".ts"],
      "ExtensionsWithNoOutput": [".d.ts"],
      "Paths": [
       { "OutputPath": "out" } 
      ]
   },
}

This chutzpah.json file is a bit more complicated than the one previously. This includes a compile setting with its mode set to External. This tells Chutzpah to assume some external process will compile the TypeScript code. As part of this setting you tell Chutzpah where to look for the generate .js files (in this case the out directory). In addition, the AMDBaseUrl and AMDAppDirectory properties are set. The AMDBaseUrl setting is used to configure what BaseUrl Chutzpah should use. By default if you set this Chutzpah will assume your AMD paths should be relative to it. However, in the case of compilation this is often not what you want. Since all the files are being compiled to a separare folder (called out) you would set the AMDBaseUrl to the out folder. This causes an issue though since you still want your AMDPath's generated relative to the source folder. To fix this you set the AMDAppDirectory to the root of your source tree. If you don't set this it will default to the test harness directory.

For more complicated examples look at the Samples folder in the source tree.