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.

### 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:

 Field Default Description Extensions [] The extensions of the files which are getting compiled (e.g. .ts). ExtensionsWithNoOutput [] The extensions of files which take part in compile but have no build output. This is used for cases like TypeScript declaration files which share a .ts extension. They have .d.ts extension and are part of compilation but have no output. You must tell Chutzpah about these if you want the SkipIfUnchanged setting to work. Otherwise Chutzpah will think these are missing output. SourceDirectory Chutzpah.json directory The root directory where all the sources the command compiles are below. This lets Chutzpah know where in the out dir it should find each reference file OutDirectory Chutzpah.json directory The directory where the compiled files are output to WorkingDirectory Chutzpah.json directory This is the working directory of the process which executes the command. Executable null The path to an executable which Chutzpah executes to perform the batch compilation. Chutzpah will try to resolve the path relative to the settings directory. But if can’t find the file there you must give it a full path. Arguments null The arguments to pass to the command Timeout 30000 (5 minutes) How long to wait for compile to finish in milliseconds? SkipIfUnchanged true Skips the execution if all files Chutzpah knows about are older than all of the output files. This is defaulted to true but if you hit issues since it is possible Chutzpah might not know about all the files your compilation is using then you can turn this off. Ideally you should tell Chutzpah about these files using the references and tests settings since this setting helps Chutzpah not need to even invoke the executable if it figures out it’s not needed. Mode Executable Determines how this compile setting is used. By default it is in Executable mode where it will require you provide an executable which Chutzpah will run if it sees it finds missing .js for input file. If you set this to External then Chutzpah will ignore the Executable, Arguments settings and assume you have some external process which is compiling. In this case Chutzpah will use the SourceDirectory and OutDirectory options to try to find your .js files for the input files. If it can’t find them it will trace an error but still attempt to proceed.

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:

 %chutzpahsettingsdir% The directory the chutzpah.json is in %clrdir% The directory to the folder where the CLR is. This folder contains programs like msbuild.exe %msbuildexe% The path to msbuild.exe %powershellexe% That path to powershell.exe %cmdexe% An alias for %comspec% which is the path to cmd.exe.

#### 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

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

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. Chutzpah 3.1 has a few improvements that were originally targeted for the 3.0 release. 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 ## Tests Setting In the 3.0 release Chutzpah added a references section that let you declare which files to include as references. In this release a similar section named Tests is added that lets you specify what tests you want to run. ### Example { "Tests": [ { "Include": "*test1*" }, { "Path": "Dir3/test.js"}, { "Path": "Dir1", "Include": "*.js", "Exclude": "*test4.js" }, { "Path": "Dir2" } ] }  • Line #3 – Includes all tests that contain test1 in its path. This is in glob format. • Line #4 – Includes the file Dir3/test.js (relative to the chtuzpah.json path). • Line #5 – Includes all *.js files in the folder Dir1 except test4.js. (Include/Exclude in glob format) • Line #6 – Includes all files in Dir2 These settings are evaluated on a first match wins policy. This means that if line #2 matches a file then #3 and #4 will not be checked for that file. Therefore, if an earlier line matches a file a later line cannot exclude that same file. ### Usage The tests setting section can be used in two ways: discovery or filtering. Discovery You can tell chutzpah.console.exe to execute a chutzpah.json file! Chutzpah will evaluate the tests settings and use it to find all files it describes. For example: chutzpah.console.exe path/to/chutzpah.json  This feature provides a nice way to simplify describing all tests you want to run without needing to explicitly list multiple /path arguments on the command line. Filtering The second way the new tests setting can be used is to filter which test files are executed. When Chutzpah is running test files it will skip ones which don’t match the tests setting. This is a *much* needed feature for the Visual Studio integration. By default the test adapter plugin will look at all *.js files and try to see if they are test files. Often Chutzpah is able to use heuristics to quickly tell if a file is a test file. If the heuristics fails it then needs to actually execute that file. This can be very slow especially if Chutzpah is doing this with a large JS library. With this tests setting feature you can help Chutzpah out by placing a chutzpah.json at the root of your project and indicate which files are the test files. This can be a big performance boost and is the recommendation for all projects. ## Jasmine 2.0 Chutzpah now ships with support for both the 2.0 and 1.0 lines of Jasmine (specifically 1.3.1 and 2.0.0). Both are supported for now since the 2.0 release broke combat with the 1.0 line. By default Chutzpah will assume you want the 2.0 version but there is a new chutpah.json setting to indicate you want the previous version. To indicate you want the 1.0 line of Jasmine add the following to your chutzpah.json file: { "FrameworkVersion": "1" }  You can put pretty much any version you want here that starts with 1 since for Jasmine Chutzpah only cares if you either want the 1.0 line or if you don’t. Eventually Chutzpah will deprecate and then remove support for Jasmine 1.0 so please begin the process of upgrading soon. Chutzpah 3.0 resolves two of the most requested features: Mocha test framework and better RequireJS support. In addition to those this release contains many bug fixes and a few smaller additions. Below I will describe in detail how to take advantage of these new features. 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 ## Improved RequireJS Support The most common source of issues for Chutzpah was people trying to get it to work with RequireJS. Although it was possible to make it to work it was very tricky and would crumble if you tried anything complicated. The new support for RequireJS should be much more flexible and allow you to run individual test files however it does require a few specific settings to work. I checked in examples for how to set this up for Mocha, QUnit, Jasmine and TypeScript. I will walk through a simplified version of the QUnit example in both JavaScript and in TypeScript. ### 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 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", "TypeScriptModuleKind": "AMD", "References" : [ { "Path": "require-2.1.8.js" }, { "Path": "require.d.ts", "IncludeInTestHarness": "false" }, { "Path": "qunit.d.ts", "IncludeInTestHarness": "false" }, { "Path": "base", "IncludeInTestHarness": "false" } ] } This chutzpah.json file is a bit more complicated than the one in the previously.It sets TypeScriptModuleKind to AMD, which tells the TypeScript compiler to emit AMD define statements. It also has a few additional References path entries. There are references for the .d.ts files to satisfy type checking. Then we reference the base folder so that Chutzpah will recursively scan that folder and find all files in it. This is important since Chutzpah needs to find all the .ts files in order to convert them to JavaScript. Chutzpah will also use these discovered .ts files to generate a RequireJS map setting that maps from the original file names to the temporary names that Chutzpah creates after conversion. All of these additional path references have IncludeInTestHarness set to false. This tells Chutzpah to not generate a script reference for these files inside of the generated test harness. For the .d.ts files we don’t want script tags and for all the files in the base directory are going to load them using RequireJS so we must not include them a second time using a script tag. For more complicated examples browse the samples folder in the Chutzpah repository. ## Mocha Test Framework Support One of the most request features was to add the Mocha test framework to the supported frameworks. Mocha presents some challenges since it is a super flexible and open ended test framework. This required several changes in Chutzpah as well as some new chutzpah.json options to make sure it is flexible enough. In the future (based on user feedback) I will try to open up the Mocha integration further to let people do things like use custom interfaces. Chutzpah supports three of the Mocha interfaces: QUnit, BDD and TDD. It will try to auto detect which one you are using but you can also specify explicitly. For example here is a basic Mocha test using the BDD interface: /// <reference path="mocha.js" /> /// <reference path="chai.js" /> var expect = chai.expect; it("A basic test", function() { expect(true).to.be.ok; var value = "hello"; expect(value).to.equal("hello"); }); Note that this file includes a ///<reference comment referencing mocha.js. This file doesn’t need to exist since Chutzpah uses its own version but this line is needed to let Chutzpah know you are using Mocha. Since Mocha’s interfaces can look like Jasmine/QUnit Chutzpah won’t auto detect that you are using Mocha. In addition, since Mocha lets you choose your assertion library the test above is referencing chai.js (this does need to exist on disk since Chutzpah does not ship with this). Putting those reference comments in every file can be annoying so you can use the Chutzpah.json file remove the need for them: { "Framework": "mocha", "MochaInterface": "bdd", "References" : [ { "Path": "chai.js" } ] } This Chutzpah.json example shows that you can set the Framework to Mocha, set the interface to BDD and then list the references you want Chutzpah to use. While you don’t always need to explicitly set the Mocha interface it doesn’t hurt to be clear with your intent. ## Customizable HTML harness generation Chutzpah tries its best to work for as many types and configurations of projects. However, there will always be projects where Chutzpah’s assumptions just don’t hold true. To help support these projects Chutzpah now allows you to take complete ownership of the template it uses to generate the html test harness. Be warned this is an advanced feature, by taking ownership of this template you are responsible for keeping it up-to-date with newer additions Chutzpah makes in later releases. Also, by editing this template Chutzpah can no longer make any guarantees that features like Code Coverage will still work. If that red text did not scare you off continue on :) To use this functionality you should start by making a copy of existing copy of the Chutzpah test harness template that is checked in (QUnit, Mocha, Jasmine). These templates contain a bunch of JavaScript and HTML embedded with special Chutzpah placeholders. These placeholders are where Chutzpah inserts text and tags it generates when examining your test files. As of version 3.0 the harness contains the following placeholders:  Placeholder Description @@TestFrameworkDependencies@@ The test framework file references (like QUnit.js) and any references marked as IsTestFrameworkFile. @@CodeCoverageDependencies@@ The code coverage framework file references (like Blanket.js). This will be empty when not running code coverage. @@ReferencedCSSFiles@@ The CSS references. @@TestHtmlTemplateFiles@@ Any test html template files discovered. @@ReferencedJSFiles@@ Reference for all JS files discovered that your test files are dependent on. @@TestJSFile@@ The reference for the file under test. This will be empty if in AMD mode. @@AMDTestPath@@ The AMD path to the file under test. @@AMDModuleMap@@ A mapping of AMD paths from original test dependencies to ones generated after running TypeScript or CoffeeScript conversion. You can edit this copy to your liking and then place it somewhere in your project. To get Chutzpah to use this template set the following in your chutzpah.json file: { "CustomTestHarnessPath": "path\\to\\customQUnit.html" } Chutzpah will use this template and generate a test harnesses out of it. ## Command line failure report flag When running Chutzpah on a large test suite from the command line it becomes difficult to see everything that failed because the failed test may be several pages up. To alleviate this problem chutzpah.console.exe contains a new flag: /showFailureReport . This flag will print a report showing all test errors and test failures at the ends of the test run. ## Chutzpah.json additions To support some of the new features and to fix existing issues the Chutzpah.json file has several new additions (many of which have been mentioned earlier in this post). Below is a complete list of the additions along with usage examples: ### References Description The references setting allows you to specify which files/folders to use/scan to find references. This is useful since it replaces the need to the ///<reference comments. This setting is a list of path entries each which can contain the following arguments:  Path The path to either a file or a folder. If given a folder, it will be scanned recursively. This path can be relative to the location of the chutzpah.json file. Include This is an optional include glob pattern. This is used when the Path is a folder. Only files matching the Include pattern will be added. Exclude This is an optional exclude glob pattern. This is used when the path is a folder. All files matching the exclude pattern will not be added. IncludeInTestHarness This determines if the reference should be injected into the test harness. When referencing files like .d.ts or files that you plan to load using require.js you should set this to false. Defaults to true. IsTestFrameworkFile Indicated that this references should be placed directly after the test framework files (like QUnit.js) in the test harness. This ensures that this file is injected into the test harness before almost all other files. Defaults to false. Examples Include files named a.js and b.js { "References": [ { "Path": "../a.js" }, { "Path": "b.js"} ] } Include all .js files in a folder unless their name contains the word Resource { "References": [ { "Path": "src/Code", "Include": "*.js", "Exclude": "*Resource*" } ] } ### TypeScriptModuleKind Description The TypeScriptModuleKind setting determines how the TypeScript compiler handles import/export statements. The options are either CommonJS or AMD. The default is CommonJS. Example { "TypeScriptModuleKind": "AMD" } ### TestHarnessReferenceMode Description The TestHarnessReferenceMode setting determines how Chutzpah should treat references to scripts and to the test file. The setting can either be Normal or AMD. Normal is how Chutzpah has always worked where it injects a script reference for your test file as well as all of its references into the HTML test harness. The AMD mode tells Chutzpah that tests using RequireJS are being used. In this case Chutzpah will not inject references or the test script into the test harness. The default value is Normal. Example { "TestHarnessReferenceMode": "AMD" } ### CustomTestHarnessPath Description The CustomTestHarnessPath setting allows you to override the default template Chutzpah uses for the HTML test harness. This is an advanced feature which was explained in detail above. Example { "CustomTestHarnessPath": "path\\to\\customQUnit.html" } ### EnableCodeCoverage Description The EnableCodeCoverage settings provides a way to have Chutzpah always run code coverage. This is important for when running on a build server where you may want Chutzpah to always collect code coverage. The default value is false. Example { "EnableCodeCoverage": "true" } ### CoffeeScriptBareMode Description The CoffeeScriptBareMode indicates if you want CoffeeScript compilation to output scripts in bare mode or not. In bare mode CoffeeScript won’t wrap the generated JavaScript in a function to protect the scope. The default value is true. Example { "CoffeeScriptBareMode": "false" } I released updates for both Chutzpah (2.5.0) and Snippet Designer (1.5.0) which adds support for Visual Studio 2013. In addition Chutzpah’s command line client now has a /trace argument that will dump detailed trace information into a file named chutzpah.log. This is useful for both debugging and filing bug reports. I plan to add much more information into this log in the upcoming releases. This release of Chutzpah contains a few bug fixes, upgraded versions of Blanket.js and TypeScript and a new feature for injecting HTML templates. ## TypeScript Upgraded Chutzpah now uses TypeScript 0.9.0.1. This change may require an update for your .ts files. In this version of TypeScript the compiler errors if you do not specify the .d.ts file corresponding to your third party JS library. For example, if you are using QUnit you must reference the QUnit.d.ts file. ## Improved Code Coverage Code coverage has improved with two changes. The version of Blanket.js was upgraded to 1.1.5. In addition, Chutzpah will now prevent files you exclude from code coverage from getting instrumented. This helps improve performance of the coverage runs. ## HTML Template Feature This feature came in as pull request from Matthew Osborn. This allows you to specify an HTML template file from your tests. Chutzpah will inject this templates content into the head section of the generated test harness. For example, lets say you have an HTML template file named template.tmpl.html with the contents: <script id="testTemplateId" type="text/html"> <div id="testTemplateDiv"> Cool! </div> </script> Then you can reference this file from your test with the syntax: /// <template path="template.tmpl.html"/> For example, this is a test case I wrote in Chutzpah to assert this feature works correctly: /// <reference path="qunit.js" /> /// <template path="template.tmpl.html"/> /// <reference path="../jquery-1.7.1.min.js" /> module("Html Template Test - QUnit"); test("Will load html template", function () { // Grab template text, convert to html, append to body$($("#testTemplateId").text()).appendTo("body"); var templateDiv =$("#testTemplateDiv");

equal(templateDiv.length, 1);
});

Which results in an HTML test harness which looks something like this:

<!DOCTYPE html>
<html>
<script type="text/javascript" src="qunit.js"></script>
<script id="testTemplateId" type="text/html">
<div id="testTemplateDiv">
Cool!
</div>
</script>
<script type="text/javascript" src="query-1.7.1.min.js"></script>
<script type="text/javascript" src="template-qunit.js"></script>
</html>