by Matthew Manela | Chutzpah

Chutzpah 3.1 – Smarter test running and Jasmine 2.0

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.

 

5 thoughts on “Chutzpah 3.1 – Smarter test running and Jasmine 2.0”

  1. I am having a really difficult time using Chutzpah with the latest version of TypeScript (1.0RC). When I try to run the tests I get errors that are similar to errors I would receive if I was trying to compile my *.ts files with an old version of tsc.exe. Is there a way around this?

    Repro steps: Use the following code:

    class Random implements IRandom {
    generateArray(method: string): Array;
    generateArray(Constructor: new () => T): Array;
    generateArray(method: any) {
    return new Array();
    }
    }

    interface IRandom {
    generateArray(method: string): Array;
    generateArray(Constructor: new () => T): Array;
    }

    Include file in a test and receive an error similar to below:

    Class Random declares interface IRandom but does not implement it:
    Types of property ‘generateArray’ of types ‘Random’ and ‘IRandom’ are incompatible:
    Call signatures of types ‘{ (method: string): T[]; (Constructor: new() => T): T[]; }’ and ‘{ (method: string): T[]; (Constructor: new() => T): T[]; }’ are incompatible:
    Types of property ‘concat’ of types ‘{}[]’ and ‘T[]’ are incompatible:
    Call signatures of types ‘{ (…items: U[]): {}[]; (…items: {}[]): {}[]; }’ and ‘{ (…items: U[]): T[]; (…items: T[]): T[]; }’ are incompatible:
    Types of property ‘pop’ of types ‘{}[]’ and ‘T[]’ are incompatible:
    Call signatures of types ‘() => {}’ and ‘() => T’ are incompatible.

    The file will not compile with TypeScript v0.9.5, but it works in 1.0RC.

    1. Chutzpah currently ships with a specific version of TypeScript embeded. As of today that version is 0.9.5. I plan to change this in the future so that Chutzpah doesn’t need to do this anymore and you just tell Chutzpah how to compile your files. In the mean while I do plan to update to the RC soon but I cannot give a ETA yet.

    2. Good to know, thanks! In the mean time I can revert to using plain JS for my tests.

  3. Just ran into a local issue with Chutzpah defaulting to 2.0. Easy to fix with your FrameworkVersion setting.

    I’m concerned about your thoughts on removing capability with older frameworks in the future. In my office, we work on a variety of different projects in different respositories. Often I will be working on a project that no one has touched in 2 years. And often, i’ll be working on something brand new and can use all the latest tools.

    Because of the latter, I tend to keep VS up to date. Because of the former, I have to be able to back up at any time. On any project, I may not have the time to update all of our tests. I also can’t go back and update older projects, because I’m not working on them right now.

    If you remove backwards compatibility, it is possible that I won’t be able to update Chutzpah to that version, since I can’t guarantee that it will work when I have to go back.

    If you left the option for us to reference our own copies of older frameworks, that would suffice!

Comments are closed.