Chutzpah 3.2 introduces a new and improved method for supporting languages which compile to JavaScript. This version puts the power in your hands to tell Chutzpah how to compile and lets Chutzpah get out of your way. As always  you can get the new bits from CodePlex, NuGet or go to the Visual Studio Gallery to get the updated Visual Studio Context Menu Extension  and Unit Test Explorer adapter.

Changes

• Smarter Compile
• Custom test function pattern
• Require.js BaseUrl support
• Bug Fixes

Smarter Compile

When I first added support for compiled languages (like TypeScript and CoffeeScript) to Chutzpah I was trying to make it super simple to use. I embedded both CoffeeScript and TypeScript inside Chutzpah and executed them at test time by hosting the IE script engine to produce the needed .js files. This approached worked ok but led to a few major issues/pain points:

1. Versioning: Chutzpah needed to ship with a specific version of TypeScript since the api’s needed to run the compilation kept changing. This led to a bad issue of a user wanting to use version X but Chutzpah only supporting Y.
2. Performance: Chutzpah’s compile was slow and not smart about when it needed to run.
3. Memory: The hosting of the IE script engine led to a native memory leak when you run your tests using VS Test Explorer.
4. Philosophical:  Chutzpah should not be responsible for determining how to compile your source code. It was a mistake to mix this concept into Chutzpah. It should have been decoupled from the start. Live and learn ;)

Given those pain points I still like the idea that you can point Chutzpah at your source files and you should still be able to get test results that point back to the test files. This led to the new chutzpah.json compile setting. This setting lets you describe in the Chutzpah.json file how to execute a command which can compile your source files to .js files. You tell Chutzpah what to execute and some information about what your executable does (like where to find the generated .js files). Then after running the executable Chutzpah can associate each source file with each output file to still give the nice behavior of mapping tests back to their original files.

You should ideally configure this compile setting to use the same mechanism you have for compiling the code in your project. This will give you a nice performance gain when running Chutzpah since it will re-use the .js files you have already built. This becomes really powerful when you are taking advantage of IDE integration features that TypeScript and CoffeeScript plugins have that provide a compile on save experience. If configured correctly Chutzpah will be able to use the the output of that feature and never need to actually invoke the compile step. This results in a *very* fast test running experience.

When Chutzpah sees that you have the compile configuration set it will not use the legacy integrated compilation.

Below are the options for the Compile setting:

For the Executable, Arguments and OutDirectory fields Chutzpah lets you put in variables which get expanded at execution time. These can be system environment variables like %comspec% as well as the set of Chutzpah provided variables below:

Integration with compilation tooling

Many users of TypeScript and CoffeeScript use IDE tooling which will already provide compilation of those files to JavaScript. In that case you should Compile Mode setting to External. This tells Chutzpah to assume that some external force is doing the compilation and that Chutzpah can just count on the JavaScript file to exist where you said they would be.

Examples

Enough talk! As part of this release I have included several examples which show different combinations of these settings. Below I will highlight three examples. One runs your compilation code using a .bat file, one uses a .ps1 file and the last runs an MSBuild project file. For each of these samples I will cover some interesting parts but for a complete picture please browse the full code of the samples.

All of the samples below assume you have tsc.exe in your system path.

Using a .bat file

This sample demonstrates compiling TypeScript files in place using a .bat filed called compile.bat.

chutzpah.json

{
 "Compile": {
   "Extensions": [".ts"],
   "ExtensionsWithNoOutput": [".d.ts"],
   "Executable": "compile.bat"
  },
 "References": [
   {"Include": "*/src/*.ts", "Exclude": "*/src/*.d.ts" }
 ],
 "Tests": [
   { "Include": "*/test/*.ts", "Exclude": "*/test/*.d.ts" }
 ]
}

compile.bat

@echo off
tsc src/code.ts test/test.ts --sourcemap

A couple interesting things about this example:

1. It doesn’t set the outdirectory since the compile.bat command is compiling them in place.
2. It gives a relative path for compile.bat since it is in the same directory as the chutzpah.json file
3. It provides .d.ts as the ExtensionsWithNoOutput since although .d.ts are part of the compilation process they produce no output. This helps Chutzpah be smart about when it needs to run the compile executable.

Using a .ps1 file

This sample demonstrates compiling TypeScript files to a out directory using a PowerShell file.

chutzpah.json

{
 "Compile": {
   "Extensions": [".ts"],
   "ExtensionsWithNoOutput": [".d.ts"],
   "OutDirectory": "out",
   "Executable": "%powershellexe%",
   "Arguments": "-NoProfile %chutzpahsettingsdir%\\compile.ps1"
  },
 "References": [
   {"Include": "*/src/*.ts", "Exclude": "*/src/*.d.ts" }
 ],
 "Tests": [
   { "Include": "*/test/*.ts", "Exclude": "*/test/*.d.ts" }
 ]
}

compile.ps1

tsc src/code.ts test/test.ts --sourcemap --declaration --outDir out

A couple interesting things about this example:

1. It sets the outdirectory in the chutzpah.json to match the outDir setting in the call to tsc.exe in compile.ps1. This tells Chutzpah where to find the .js files.
2. It uses the %powershellexe% variable that Chutzpah provides to get the full path to powershell.exe in the executable field.
3. It uses the %chutzpahsettingsdir% variable in the arguments field to build the full path to the compile.ps1.

Using an MSBuild project file

This sample demonstrates compiling TypeScript files to an out directory by executing a target in an MSBuild project file.

chutzpah.json

{
 "Compile": {
   "Extensions": [".ts"],
   "ExtensionsWithNoOutput": [".d.ts"],
   "Executable": "%msbuildexe%",
   "Arguments": "/t:CompileTS ",
   "OutDirectory": "out"
  },
 "References": [
   {"Include": "*/src/*.ts", "Exclude": "*/src/*.d.ts" }
 ],
 "Tests": [
   { "Include": "*/test/*.ts", "Exclude": "*/test/*.d.ts" }
 ]
}

compile.proj

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="12.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

 <PropertyGroup>
   <TscExe>tsc</TscExe>
 </PropertyGroup>

 <Target Name="CompileTS">
   <Exec Command="$(TscExe) src/code.ts test/test.ts --declaration --sourcemap --outdir out" />
 </Target>

</Project>

A couple interesting things about this example:

1. The %msbuildexe% variable that Chutzpah provides is used in the executable field to get the full path to msbuild.exe.
2. The arguments field calls the compile.proj using a specific target (CompileTS). You may notice this command doesn’t mention the project file compile.proj. In this sample it is assuming that is the only project file. If you wanted to be explicit you could change the arguments to: compile.proj /t:CompileTS

Future of the legacy TypeScript and CoffeScript integration

With the addition of the compile configuration setting I am deprecating the legacy (that is what I am calling it) existing integrated compilation functionality. For this release the legacy code is still there but it will no longer receive updates (besides upgrading TypeScript to 1.0 when it is released). In a future release I may REMOVE the legacy compilation support so please start the process of upgrading to the new compile setting.

Custom test function pattern

When Chutzpah reports test results it also tells you what line they are on. The way this is accomplished is by having a regex for each testing framework which describes where to find the names of your tests. For example for QUnit Chutzpah uses the following:

((?<!\.)\b(?:QUnit\.)?(test|asyncTest)[\t ]*\([\t ]*["'](?<TestName>.*)["'])

This works pretty well but if you use a library which provides a different syntax for specifying tests then this will fail. This results in all tests having no line number information. To fix this problem Chutzpah now offers a TestPattern setting in the chutzpah.json file. This lets you specify your own regex for Chutzpah to use. The requirement for this regex is that it needs to capture the name of the test in a capture group called TestName. For example lets say this is how your test file looks:

function TestClass() {

}

TestClass.prototype.test = function(name, callback) {
    QUnit.test(name, callback);
};

TestClass.prototype.testCase = function (name, callback) {
    QUnit.test(name, callback);
};

TestClass.prototype.registerTests = function(callback) {
    callback.call(this);
};

var testClass = new TestClass();

testClass.registerTests(function() {
    this.test("Pattern 1", function() {
        ok(true, "this test is fine");
    });

    this.testCase("Pattern 2", function () {
        ok(true, "this test is fine");
    });

});

Then you can use the following chutzpah.json to get correct line number information.

{
    "Framework": "qunit",
    "TestPattern": "this\\.(testCase|test)\\([\"'](?<TestName>.*)[\"']"
}

Require.js BaseUrl support

One of the issues that users reported after the addition of the improved Require.js support in the 3.0 release was that it doesn’t work correctly when you set a custom BaseUrl in the Require.js config or if you set a custom test harness location in the chutzpah.json file.  With this release Chutzpah contains a setting in the chutzpah.json file called AMDBasePath. This setting is a path relative to the settings file directory which should point to the same folder as your require.js baseurl. In addition, Chutzpah will also now correctly work when you use its AMD mode while setting a custom TestHarnessDirectory. To demonstrate the use of these changes I created three new samples.

CustomBaseUrl Sample – This sample demonstrates using Require.js with a baseurl setting along with the Chutzpah AMDBasePath setting.

CustomHarnessLocation Sample – This sample demonstrates placing your tests in a separate folder than your source but placing the generated HTML file at the root of your source.

CustomBaseUrlAndCustomHarnessLocation Sample – This sample shows a combination of both samples above.