Quantcast
Channel: Chutzpah - A JavaScript Test Runner
Viewing all 1864 articles
Browse latest View live

Updated Wiki: coverage

$
0
0

Code Coverage in Chutzpah

Chutzpah’s new code coverage features is built on top of the great open source library Blanket.js. When you run with code coverage enabled it will use Blanket.js to instrument the files under test and gather the coverage results. You can perform code coverage from the command line and both Visual Studio plugins.

Command Line

To get code coverage from the command line you pass the /coverage flag to chutzpah.console.exe.

chutzpah.console.exe /coverage /path test.js


After this command finishes you will have a two files placed in your current directory

_Chutzpah.coverage.html – The rendered html results
_Chutzpah.coverage.json – The raw json results

When you open the results html file you will see something like:

coverageResults.png

Visual Studio Context Menu Extension

The Visual Studio Context Menu Extension now contains a Show Code Coverage command which will perform code coverage and open the results in a browser.

contextCoverage.png

Visual Studio 2012 Test Adapter Extension

For the Unit Test Explorer adapter for Visual Studio 2012 Chutzpah piggybacks on the existing “Analyze Code Coverage” menu option and uses it to run with code coverage and show the results in a browser. Ideally, Chutzpah would integrate into the code coverage reporting built into VS but I was unable to figure out a good way to plug in to that. The side effect is that when you run this command VS will open their results window first (with nothing in it) and then Chutzpah will launch its results in a browser.


adapterCoverage.png

NOTE: I have noticed some performance issues when running “Analyze Code Coverage for All Tests” command. I think it might be VS doing extra work for no reason since it is trying to generate its own report.


Configuration Code Coverage

Being able to run code coverage is not enough since in many cases the results will not be accurate. For example, if your project uses jQuery you do not expect your test to cover all the lines of jQuery’s source code (that would be one impressive test). Therefore you need to exclude files/directories from participating in code coverage. There are two way you can do that with Chutpah: command line arguments or a chutzpah.json file.

If you are running Chutzpah from the command line there are two additional arguments you can pass coverageIncludes and coverageExcludes. These are a comma separated list of files/paths you want to include or exclude from coverage. They can use a glob format where * matches zero or more characters and ? matches one character. For example:

Exclude files that ends in matt.js
chutzpah.console.exe /path test.js /coverage /coverageExcludes *matt.js 


Include only dog.js and any file with a single character extension
chutzpah.console.exe /path test.js /coverage /coverageIncludes "*\dog.js, *.?" 


Include *query.js but exclude jQuery.js
chutzpah.console.exe /path test.js /coverage /coverageIncludes *query.js /coverageExcludes *\jquery.js


The other option for configuring code coverage is the chutzpah.json file. There are two new setting which you can use CodeCoverageExcludes and CodeCoverageIncludes. These settings work in the same way as the their command line counterpart. The main difference is that you must escape backslashes.

{
  "CodeCoverageExcludes": ["*\\jquery.js"],
  "CodeCoverageIncludes": ["*query.js", "*\\dog.js"]
} 


You can also force coverage to always be gathered by setting EnabledCodeCoverage to true. This is very useful when running Chutzpah in a build server.

{
  "EnableCodeCoverage": "true"
}

Updated Release: Sample Tests (Sep 11, 2011)

$
0
0
This zip contains a sample QUnit, Jasmine, Mocha tests that demonstrate both normal test running and using RequireJS.

Released: Sample Tests (Dec 12, 2013)

$
0
0
This zip contains a sample QUnit, Jasmine, Mocha tests that demonstrate both normal test running and using RequireJS.

Updated Release: Sample Tests (Dec 12, 2013)

$
0
0
This zip contains a sample QUnit, Jasmine, Mocha tests that demonstrate both normal test running and using RequireJS.

Updated Release: Chutzpah 3.0.0 (Dec 12, 2013)

$
0
0

Released: Chutzpah 3.0.0 (Dec 12, 2013)

Updated Release: Chutzpah 3.0.0 (Dec 12, 2013)

Created Unassigned: JavaScript tests disappeared in VS 2013 [186]

$
0
0
Several people on my team installed 3.0.0 today and now we don't see any tests in Visual Studio 2013 Test Explorer. Is there something we're supposed to do to see our tests?

Updated Wiki: Chutzpah.json Settings File

$
0
0

Using the Chutzpah.json Settings File

The Chutzpah settings file is an .json file that you can place anywhere in your testing directories to inform Chutzpah of test specific settings. The Chuzpah settings file is completely optional and if the file or any of its properties are omitted Chutzpah will use the default values.

When Chutzpah is run on a file (lets say test.js) it scans the current directory for a file named chutzpah.json. If it does not find one it will recursively traverse up the directory chain looking for one. This behavior provides a lot of flexibility since you can provide multiple chutzpah.json files in your tree and each one will work over its sub-folder. This lets you have different settings for different groups of tests.

The settings file is a text file with json content of the following format:

{
    "Framework": "qunit|jasmine|mocha",
    
    "TestFileTimeout": "<Timeout in milliseconds>",
    
    "TestHarnessLocationMode": "TestFileAdjacent|SettingsFileAdjacent|Custom",
    
    "TestHarnessDirectory": "<Path to a folder>",

    "TestHarnessReferenceMode": "Normal|AMD",

    "TypeScriptCodeGenTarget" : "ES3|ES5",

    "TypeScriptModuleKind" : "CommonJS|AMD",
    
    "RootReferencePathMode":"DriveRoot|SettingsFileDirectory",
    
    "CodeCoverageIncludes": [],
    
    "CodeCoverageExcludes": [],

    "EnableCodeCoverage": "true|false",

    "References": [],

    "CoffeeScriptBareMode": "true|false",

    "CustomTestHarnessPath": "<Path to custom test harness file>"

}

The chutzpah.json file supports the following properties

Framework– Determines what testing framework to use. This will override the other detection methods. This is helpful if Chutzpah is having trouble figuring out what your intended framework is. If left out Chutzpah will automatically try to detect the framework.

TestFileTimeout - The time to wait for tests in a file to finish in milliseconds

TestHarnessLocationMode– Determines where to place the generated html test harness files. The default mode is TestFileAdjacent which means the harness is placed in the same directory as the test file. SettingsFileAdjacent means it is placed in the same directory as the chutzpah.json file. Custom mode lets you specify a custom path to the directory.

TestHarnessDirectory– When TestHarnessLocationMode is set to Custom this is either the relative or absolute path to the directory where to place the test harness.

TypeScriptCodeGenTarget– When running on a TypeScript file this property will tell the TypeScript compiler what type of code to generate. ES3 is for ECMAScript 3 and ES5 is for ECMAScript 5.

RootReferencePathMode– This property determines what directory a rooted reference path refers to. In a test file Chutzpah parses the <reference path="" /> tags to determine your test dependencies. By default (the DriveRoot setting) if you write <reference path="\a.js" /> Chutzpah will look for a.js under C:\ (assuming you are running your test in the C drive). However, if you set this property to SettingsFileDirectory Chutpah will now look for a.js relative to the location of the chutzpah.json file. This is useful if you have a large project and want to minimize the number of long reference paths.

CodeCoverageIncludes - The collection code coverage file patterns to include in coverage. These are in glob format. If you specify none all files are included.

CodeCoverageExcludes - The collection code coverage file patterns to exclude in coverage. These are in glob format. If you specify none no files are excluded.

CustomTestHarnessPath - The CustomTestHarnessPath setting allows you to override the default template Chutzpah uses for the HTML test harness. This is an advanced feature which should only be used as a last resort. Read how to use it in Customizable HTML harness generation.

CoffeeScriptBareMode - 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.

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

This file tells Chutzpah to use QUnit and to place the test harness next to the chutzpah.json file:
{
    "Framework": "qunit",
    "TestHarnessLocationMode": "SettingsFileAdjacent"
}

This file tells Chutzpah to convert TypeScript to ES5 code and to place the test harness in a custom directory:
{
    "TypeScriptCodeGenTarget" : "ES5",
    "TestHarnessLocationMode": "Custom",
    "TestHarnessDirectory": "../Some/Folder"
}

When run with Code Coverage this file tells Chutzpah to exclude files named jquery.js and include files that have a suffix of query.js or are named dogs.js:
{
    "CodeCoverageExcludes": ["*\\jquery.js"],
    "CodeCoverageIncludes": ["*query.js", "*\\dog.js"]
} 

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*" }
    ]
}

Commented Unassigned: Expose option for compiling CS non-bare [170]

$
0
0
I just encountered a bug that slipped through my tests since Chutzpah compiles CoffeeScript in bare mode.

I see in the code that it's possible to set the compilation to non-bare, but I don't see an exposed option for it. It would be very useful to have one!
Comments: [Version 3.0 of Chutzpah](http://matthewmanela.com/blog/chutzpah-3-0-mocha-requirejs-and-more/) contains a chutzpah.json setting for toggling CoffeeScript bare mode.

Edited Unassigned: Expose option for compiling CS non-bare [170]

$
0
0
I just encountered a bug that slipped through my tests since Chutzpah compiles CoffeeScript in bare mode.

I see in the code that it's possible to set the compilation to non-bare, but I don't see an exposed option for it. It would be very useful to have one!

Commented Feature: Allow failure reports after command line run [147]

$
0
0
In a project that I'm working on we currently have around 300 very verbose tests. Chutzpah is integrated into the build system so we run the following command at build time:

```
chutzpah.console.exe myTestSuite.html /silent /debug /timeoutMilliseconds 30000
```

Now the output of the tests is very verbose so the console is then flooded with log messages (a good thing). On occasion there'll be failing tests and the console will contain something like "x number of tests failed" etc. at the very end of the exe run. This is great in determining that tests failed but not so great in determining which tests and why they failed.

In essence I could scroll up and look through the several thousand lines of debug output in an attempt to find out what tests failed and why but with so many lines of output it becomes pretty impossible.

It'd be great if the debug option also re-output the failing tests and their corresponding logs at the end of the test run. This way all failures are in one location and are easy to decipher potential failure causes.
Comments: This feature has now been release in [version 3.0](http://matthewmanela.com/blog/chutzpah-3-0-mocha-requirejs-and-more/)

Commented Unassigned: VS2013 New Tests don't show up in Test Explorer [154]

$
0
0
I had a file with "test" in it. It showed up in TE, ran and passed. I then added "test2" and it never shows up in TE.

Using jasmine

describe('test', function () {
it('basic', function () {
expect(true);
});
});

describe('test2', function () {
it('basic', function () {
expect(true);
});
});

And this chutzpah.json

{
"Framework": "jasmine",

"TestFileTimeout": "3000",

"TestHarnessLocationMode": "SettingsFileAdjacent",

"TypeScriptCodeGenTarget" : "ES5",

"RootReferencePathMode":"SettingsFileDirectory",

"CodeCoverageIncludes": [],

"CodeCoverageExcludes": []
}
Comments: This feature has now been release in [version 3.0](http://matthewmanela.com/blog/chutzpah-3-0-mocha-requirejs-and-more/)

Edited Issue: Can't find variable [71]

$
0
0
What am I doing wrong here? I'm using web essentials. I tried both AMD module syntax and commonjs.

common.auth.ts

import api = module("lib/api")
export function getAuthorizationHeader(): string {
...
}

export function setAuthorizationHeader(val: string): string {
...
}

my test.ts:

///<reference path="../dep/qunit/qunit.d.ts"/>
///<reference path="../lib/common.auth.ts"/>
///<reference path="../lib/common.auth.js"/>

import Auth = module('lib/common.auth')

test("authorization header is set", () => {

// arrange
var key = "Bearer ABDE1234";

// act
Auth.setAuthorizationHeader(key);
var header = Auth.getAuthorizationHeader();

// assert
ok(header === key, "The actual header does not match");

});

Chutzpah.auth.js:7: Can't find variable: Auth

Commented Issue: Can't find variable [71]

$
0
0
What am I doing wrong here? I'm using web essentials. I tried both AMD module syntax and commonjs.

common.auth.ts

import api = module("lib/api")
export function getAuthorizationHeader(): string {
...
}

export function setAuthorizationHeader(val: string): string {
...
}

my test.ts:

///<reference path="../dep/qunit/qunit.d.ts"/>
///<reference path="../lib/common.auth.ts"/>
///<reference path="../lib/common.auth.js"/>

import Auth = module('lib/common.auth')

test("authorization header is set", () => {

// arrange
var key = "Bearer ABDE1234";

// act
Auth.setAuthorizationHeader(key);
var header = Auth.getAuthorizationHeader();

// assert
ok(header === key, "The actual header does not match");

});

Chutzpah.auth.js:7: Can't find variable: Auth
Comments: Much improved AMD support has been release in [version 3.0](http://matthewmanela.com/blog/chutzpah-3-0-mocha-requirejs-and-more/)

Commented Issue: Form submission causes test run to hang and eventually timeout [87]

$
0
0
We have a test suite which has recently grown to just over 200 tests. Recently I have started experiencing an issue on our build server whereby the test run appears to hang at around 150 tests and subsequently bombs out with a ChutzpahTimeoutException. Interestingly the number of tests after which it hangs varies between runs, but is always around 150.

We can run the tests locally fine, but our development machines are quite powerful compared to the build server.

I am using Chutzpah 2.2.1.173 and our tests are written in Jasmine using RequireJS.
Comments: The imrpoved AMD support has been release in [version 3.0](http://matthewmanela.com/blog/chutzpah-3-0-mocha-requirejs-and-more/)

Commented Issue: Form submission causes test run to hang and eventually timeout [87]

$
0
0
We have a test suite which has recently grown to just over 200 tests. Recently I have started experiencing an issue on our build server whereby the test run appears to hang at around 150 tests and subsequently bombs out with a ChutzpahTimeoutException. Interestingly the number of tests after which it hangs varies between runs, but is always around 150.

We can run the tests locally fine, but our development machines are quite powerful compared to the build server.

I am using Chutzpah 2.2.1.173 and our tests are written in Jasmine using RequireJS.
Comments: The imrpoved AMD support has been released in [version 3.0](http://matthewmanela.com/blog/chutzpah-3-0-mocha-requirejs-and-more/)

Commented Issue: Form submission causes test run to hang and eventually timeout [87]

$
0
0
We have a test suite which has recently grown to just over 200 tests. Recently I have started experiencing an issue on our build server whereby the test run appears to hang at around 150 tests and subsequently bombs out with a ChutzpahTimeoutException. Interestingly the number of tests after which it hangs varies between runs, but is always around 150.

We can run the tests locally fine, but our development machines are quite powerful compared to the build server.

I am using Chutzpah 2.2.1.173 and our tests are written in Jasmine using RequireJS.
Comments: The improved AMD support has been released in [version 3.0](http://matthewmanela.com/blog/chutzpah-3-0-mocha-requirejs-and-more/)

Commented Feature: Customizable HTML Harnesses [124]

$
0
0
Chutzpah is a more effective test runner when you can run directly on your js/coffee/ts files however for some scenarios (like with AMD) you want more control and need to author your own test harness file. To bridge this gap Chutzpah should provide a test harness template feature.

Using this you will be able to specify in your chutzpah.json a path to a test harness template. In this template you will be able to tell Chutzpah where to put the test files, js files etc. For example this is currently what Chutzpah uses internally for a qunit HTML test harness template:

```
<!DOCTYPE html>
<html>
<head>
@@TestFrameworkDependencies@@
@@ReferencedCSSFiles@@
@@ReferencedJSFiles@@
@@TestJSFile@@
</head>

<body>
<h1 id="qunit-header">Unit Tests</h1>
<h2 id="qunit-banner"></h2>
<h2 id="qunit-userAgent"></h2>
<ol id="qunit-tests"></ol>
<div id="qunit-fixture"></div>
</body>
</html>

```
The words with @@ around them are placeholders that Chutzpah fills in for you. I think this method will allow people to have full customizablity and still get the benefits of running on JS files.
Comments: The customizable test harness feature has been released in [version 3.0](http://matthewmanela.com/blog/chutzpah-3-0-mocha-requirejs-and-more/)

Edited Feature: Customizable HTML Harnesses [124]

$
0
0
Chutzpah is a more effective test runner when you can run directly on your js/coffee/ts files however for some scenarios (like with AMD) you want more control and need to author your own test harness file. To bridge this gap Chutzpah should provide a test harness template feature.

Using this you will be able to specify in your chutzpah.json a path to a test harness template. In this template you will be able to tell Chutzpah where to put the test files, js files etc. For example this is currently what Chutzpah uses internally for a qunit HTML test harness template:

```
<!DOCTYPE html>
<html>
<head>
@@TestFrameworkDependencies@@
@@ReferencedCSSFiles@@
@@ReferencedJSFiles@@
@@TestJSFile@@
</head>

<body>
<h1 id="qunit-header">Unit Tests</h1>
<h2 id="qunit-banner"></h2>
<h2 id="qunit-userAgent"></h2>
<ol id="qunit-tests"></ol>
<div id="qunit-fixture"></div>
</body>
</html>

```
The words with @@ around them are placeholders that Chutzpah fills in for you. I think this method will allow people to have full customizablity and still get the benefits of running on JS files.
Viewing all 1864 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>