Chutzpah 4.3.0 – Web Server Mode

Chutzpah 4.3.0 is now available and its largest new feature is Web Server mode.

Web Server Mode

Chutzpah historically built your test harness using local file paths (e.g. file:///some/path.js).  This has worked well for the most part but has problems like causing cross-origin errors when opening the generated harness in the browser and complicating testing applications built with SystemJS. To resolve these issues and overall make Chutzpah more modern I have added a Web Server mode. This is an opt-in feature but after getting feedback and vetting I plan to make this the default in a future release. When this mode is enabled a local server (using Kestrel) will be hosted to serve your files.

To configure web server mode add a Server section to the chutzpah.json file:

This enables the server mode and uses default values for the default port (9876) and root path of the server (drive root). If the default port is not available it will increment the port number until it finds an open one.

You can configure the default port and root path:

 

Jacoco.xml coverage format

You can now export the results of code coverage in the jacoco.xml format.

chutzpah.console.exe myFile.js /coverage /jacoco cov.xml

This makes integrating Chutzpah code coverage results into a Visual Studio Team Services build simple by publishing the generated XML file:

image

image

 

Code Coverage Timeout

You can now configure how long to wait to instrument each file before timing out. By default this is 5000 ms but using the CodeCoverageTimeout setting you can make this larger.

 

Code Coverage and Angular2 / SystemJS

If you are using Angular2 or SystemJS code coverage will not work. Chutzpah uses the Blanket.js library to handle code coverage and it does not (and probably never will) support SystemJS. I plan to update Chutzpah in the future to move away from Blanket.js and use the Istanbul coverage library instead. I do no have a time frame yet for this change and PR’s are welcome Smile.

 

Pin a work item query in VS Code

A couple weeks ago the VSTS Extension for VS Code was released. This extension adds command and status bar integration for Visual Studio Team Services. When using this extension I loved seeing the number of pull requests and the build state in the status bar but I wished I could see the count of bugs assigned to me. About a week ago I forked the project to see how hard it would be to add this feature. To my surprise it was very simple. Jeff Young did a great job with the extension, it is well structured and easy to jump into. After a few hours I built the Pinned Query feature.

A pinned query is a work item query that runs in the status bar and shows you a count of how many items it returns (see the cute little bug icon). When you click on the icon it will run the query and give you the results.

image

By default it is set to a built in query showing all the work items assigned to you but you can easily customize the pinned query in your user settings file. You can configure using a path to an existing query or by providing WIQL:

Using Query Text

 "team.pinnedQueries": [
        {
            "account": "your-account-name",
            "queryText": "SELECT * FROM WorkItems WHERE [System.AssignedTo] = @me AND [System.ChangedDate] > @Today - 14"
        }
    ]

Using Query Path

    "team.pinnedQueries": [
        {
            "account": "your-account-name",
            "queryPath": "Shared Queries/My Folder/My Query"
        }
    ]

You can also create a global pinned query which will be the default if you have not configured one for your account by replacing your-account-name with global in the previous examples.

 

Automate Visual Studio Team Services with PowerShell

One of the main skills programmers have is the ability to automate the mundane. In my day to day job of both working on and with Visual Studio Team Services (VSTS) I find myself performing many of the same tasks over and over. And whenever these tasks require me to leave the comfort of my PowerShell prompt I get grumpy. Since I rather not be grump I created a project called PsVsts to help me automate those tasks.

PsVsts is a PowerShell module which provides several handy commandlets for working with VSTS. The point of this project is not to simply create a wrapper around the public REST apis but to lift those apis up a level to make them more convinient to use. Because of that many of commandlets consume multiple APIs.

The project currently contains the following commandlets:

  • Get-MyWorkItems Gets the work items that are assigned to or created by you. Provides easy way to filter by open vs finished items.
  • Get-WorkItems Gets the work items given a query.
  • Open-WorkItems Opens work items in your web browser.
  • Push-ToVsts
    Takes a local git repo, creates a corresponding repo in your VSTS project, adds that repo as a remote origin and pushes your local repo to it.
  • Submit-PullRequest Submits a pull request
  • Get-Builds Gets a list of builds
  • Set-VstsConfig Sets a config value for use in other PsVsts functions
  • Get-VstsConfig Gets the config values

 

The commands I use most often are the Get-MyWorkItems and Submit-PullRequest. The Submit-PullRequest commandlet wraps both the pull request and identity apis to allow me to easily create a PR and add reviewers using their name or email. I use this commandlet as part of function in my PowerShell profile to automate my common worflow to make changes and submit them for review:

function fastFix($branchName, $title) {
  
  if((-not $branchName) -or (-not $title)) {
    throw "You must specify branchName and title"
    return
  }
  
  Write-Host "Checking out $branchName"
  git checkout -b $branchName
  
  Write-Host "Adding all files and committing"
  git commit -am $title
  
  Write-Host "Pushing to server"
  git push -u origin $branchName
  
  Write-Host "Submit Pull Request"
  Submit-PullRequest -Title $title -Description $title -SourceBranch $branchName -TargetBranch master -Project MyProject -Account MyAccount -Repository MyRepo
  
}

I use the Get-MyWorkItems commandlet to quickly see what is assigned to me and then I can pipe that to Open-WorkItems to view them in the browser. By default this commandlet will try to show only open items.

Get-MyWorkitems -AssignedToMe | Open-WorkItems.

 

You can easily install these commandlets on your machine using the PsVsts Chocolatey package.

choco install psvsts

I hope these may be of help to any other PowerShell users who also loathe being grumpy :)

 

Chutzpah 4.1 – Visual Studio Debugger Support

A week ago Chutzpah 4.1 which finally adds the ability to debug your unit tests directly from Visual Studio.

 

Changes

 

Debugging from Visual Studio

Thanks to the awesome PR of Martin Connell you can now debug your JS tests from inside of the IDE. You can set breakpoints in your JS files and launch using the Visual Studio Debugger by clicking:

Debug Tests when using the Chutzpah Test Adapter Plugin

or

Run Chutzpah With -> Debugger when using the Chutzpah Context Menu Extension

Chutzpah will then launch Internet Explorer and attach the Visual Studio Debugger to it.

 

NOTE: Before this will work you must ensure script debugging is enabled in IE by going Tools->Internet Options->Advanced and unchecking both Disable script debugging settings.

 

Chutzpah 4.0 – Batching, Inheritance and more

Chutzpah 4.0 cleans up some of the legacy baggage while adding the much requested feature of test file batching.

Changes


Test File Batching

Chutzpah has always created an HTML harness for each of your test files. This has the advantage of isolated one test from another but it has the big draw back of limiting throughput of running all your tests. Especially for people with large suite of tests parallel execution of individual test harnesses will not be as fast as batching them all together in one harness. With this release Chutzpah now adds support for both modes. When you set the following in your chutzpah.json file:

"EnableTestFileBatching": true

It tells Chutzpah to put all the test files under this chutzpah.json file into one HTML harness (see full sample). Because the settings file determines the grouping of files that get combined into one harness it gives you the ability to determine what tests you want to get loaded into one harness. Chutzpah can then run those harness in parallel which can give you increased throughput. In the future (based on user feedback) batching may become the default.

 

Settings File Inheritance

The addition of the test file batching feature above encourages the use of multiple chutzpah.json files to help control how files are batched and parallelized. This presents a problem though since your project will often have a set of common files and you would rather not list them multiple times in different settings files. To address this you can now inherit settings from a parent chutzpah.json file. In your chutzpah.json file (see full sample) you write:

"InheritFromParent": true

Which instructs Chutzpah to traverse recursively up the folder hierarchy and look for another chutzpah.json file. If found it will merge the two files and combine their settings. The inheritance between a parent and child settings works as follows when both the parent and child files contain the same setting:

Setting Name What happens?
References References from child template are prepended with the references from the parent template
Templates Templates from the child template are prepended with the templates from the parent template
Tests Not inherited
*All Others* Child template overwrites the parent template setting

 

Multiple Includes/Excludes for Tests and References Settings

The Tests and References settings now have Excludes and Includes properties (in addition to the old singular Exclude and Include setting). The new plural settings let you specify an array of patterns. This provides more flexibility when describing what files you do and do not want to include for a folder. For example:

{
    "Tests": [
        { "Path": "someFolder/someOtherFolder", "Includes": [ "*Dir1/*.js", "*Dir2/*.js"], "Excludes": [ "*Dir1/test4.js", "*Dir2/test2.js" ] }
    ]
}

 

Legacy Compilation Support Removed

The 4.0 release removes the legacy compilation support. Chutzpah no longer ships with a built in TypeScript and CoffeeScript compiler. Please use the compile setting now to configure how Chutzpah handles TypeScript or CoffeeScript files.