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.


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




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


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.


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.


Chutzpah 3.3.0

Chutzpah 3.3.0 is now available at your usual locations.


  • Update to QUnit 1.16
  • Update to Jasmine 2.1.3
  • Improve parsing of Chutzpah.json files (finally allow comments)
  • Skip paths that are too long while discovering tests
  • Integrate test result transformers into Chutzpah.json file
  • Add LCOV test result transformer
  • Add TRX test result transformer
  • Add source map support for code coverage
  • Fix issue with requirejs urls containing querystrings
  • Move HTML template injection from HEAD tag to BODY tag


Test Result Transforms

Chutzpah has long had support to transform your test results into the JUnit XML format but this was only exposed from the command line. With recent additions this feature has been greatly improved: Chutzpah now supports JUnit, LCOV (for code coverage) and TRX file formats. In addition, you can now specify what transforms you want and where the output files should live using the chutzpah.json file.

For example the settings below will output the results as lcov, trx and junit to the specified paths whenever Chutzpah runs.

    "Transforms": [
        { "Name": "lcov", "Path": "C:\temp\lcov.dat" },
        { "Name": "junit", "Path": "C:\temp\junit.xml" },
        { "Name": "trx", "Path": "C:\temp\trx.trx" }


Code Coverage Source Map Support

One annoyance with Chutzpah’s code coverage was that is always showed coverage in terms of the .js files even if your source files were TypeScript or CoffeeScript. To address that problem this release contains a new option as part of the compile settings called UseSourceMaps. This will instruct Chutzpah to look for source map files in your configured compile output directory. If it finds them it will map your coverage results to the lines of the source files and generate the coverage HTML accordingly.

Here is an example config using this setting:

    "Compile": {
        "UseSourceMaps": true,
        "Mode": "External",
        "Extensions": [ ".ts" ],
        "ExtensionsWithNoOutput": [ ".d.ts" ]
    "Tests": [
        { "Path": "Tests.ts" }
    "References": [ 
        { "Path": "SourceMappedLibrary.ts" }
    "CodeCoverageExcludes": ["*Tests.ts"]