Headless Javascript Testing with Visual Studio 2012 & Chutzpah Test Adapter

[Update: The amazing @mmanela has fixed the bug in my original video.  Get the latest Chutzpah from VS Extensions.  I’ve re-recorded the video also.]

More often than not, I’ll use the jasmine-node nodejs module for javascript testing.  It provides continuous testing/auto testing and it’s really fast.  To date, there really hasn’t been a good, if any, testing experience for javascript inside-the-box for Visual Studio.

In VS 2010, the Chutzpah extension tacked on jasmine and qunit support by running javascript tests outside of Visual Studio and pushing the results to the output window.  This was a big step forward.

In VS 2012, there is an open model for discovering and executing tests that Chutzpah and others have provided implementations for.  Now you can run NUnit, xUnit, Jasmine, and QUnit tests without 4 different runners.  Much nicer.  It even supports auto/continuous testing, though with an admittedly naive priority scheme compared to NCrunch or Mighty Moose.

Video: Jasmine Tests with Chutzpah in VS 2012

In this video, I’ve walked through a very simple setup using Chutzpah to run Jasmine tests inside Visual Studio 2012 RC.

 

Failing Builds Aren’t Your Problem

Lets just say, as a group, we don’t have a lot of urgency to fix the builds

~ Concerned Team Member at Big Company

It’s a Signal, Not a Problem

I remember building my first significant build system based on CruiseControl.net, nunit, Wix, and a LOT of pixie dust.  Every failed build resulted in a friendly reminder that the team should “probably fix that.”  I’d give them some time of course, but I was always the build jerk.

It took quite a while before I started realizing that when people don’t care about the quality practices or signals that I cared about, I needed to ask why they don’t care; not what’s wrong with them.

Why A Failed Build Isn’t Important

One of the reasons I see teams ignoring their builds is because their builds don’t have any meaning to them.  They don’t produce useful information they don’t already know.  The team knows the tests are crap or the product isn’t ready for prime time.  In these cases, the feedback loop provided by the build is not in sync with the feedback loop that the team finds important.

Make The Build Important

Telling team’s that their build is important won’t work.  The build actually needs to be important.

How do you do this?

One way is to ship something!  If your not lucky enough to have leadership that supports incremental deliver, try making your Daily Scrum more productive/valuable.  The three questions and your Daily Scrum are not useful if your build isn’t also useful.  I can almost guarantee that.  So here’s how I’d suggest your team, not each individual, answer the 3 questions:

  • What new features did your builds include yesterday?
  • What stopped you from adding a feature you planned on yesterday?
  • What new features do you plan to add to the build today?

Now instead of giving some punk your status update… your making a plan to attack the day and measuring your progress in the Sprint using features running off the build.

“We’re Agile, We do Scrum”

A recent discussion that included a variation on the phrase “We’re Agile, we do Scrum” spurred me to poll our AIS team members and follow up with a blog post.  I wanted to share that blog post with you all as well.

Scrum Is the Means, Not the End

Here at Applied information Sciences, we use Yammer quite a bit to facilitate quick, transparent and open communication. For such a distributed team of smart individuals, it’s an invaluable tool to building camaraderie and cohesiveness. Yammer allows us to discuss hot industry technologies and opens the channel to shared experiences and knowledge.

What do you think?  Am I making too much of this? 

Terrible Exception message building custom Nuget VSIX Extension

Today I was putting together a custom build of the Nuget 2.0 Visual Studio Extension (VSIX).  My client has an extranet where they publish their Nuget feed(s) and it’s behind an authenticated proxy server.  It used to be that the extension would use the VS credentials, but there’s a bug in 2.0.

It’s been fixed in changeset 14dd5c2aa14b.

Pulling the Code

Head over to Codeplex and get your environment setup.  Basically means pulling the source and installing the VS 2010 SDK.

Before we just build the tip of nuget, I want to limit my exposure.  I’m going to head back in time to the 2.0 build and then apply the changeset that fixes my problem.  2.0-public is the git tag for the 2.0 release (it would seem).  So I’m going to check that tag out to a branch called authfix.

git checkout 2.0-public –b authfix

imageNow I have 2.0 on which I can cherry pick the changeset with our fix (14dd5c2aa14b).   Looking at gitk or git log will show me I have 2.0-public with the authfix applied.  I don’t have all the other features that have yet to ship since 2.0, which I don’t want, because I’m not confident in them yet and don’t want that risk yet.

Building Nuget

The Nuget contribution documentation suggests building with build.cmd.  As of 2.0 you need VS 2012 build targets, but if you don’t plan to use 2012 then you don’t actually need those targets.  You want it, but don’t need it.  This client isn’t using 2012 (yet) so I’m building in 2010.

Open Nuget.sln in VS and build it which results in:

Exception has been thrown by the target of an invocation.

image

Awesome.  Very insightful. #facepalm

 

The Real Problem

VS Extension projects deploy the extension on build so that you can debug them in an clean, isolated Visual Studio instance.  I should have remembered this from creating my Gister extension.  Turns out VS fails in this deployment when the extension has otherwise been installed.  Not so clean, but oh well.

 

imageOption A: Uninstall Nuget

Since I’ll be installing this custom build anyway, I went ahead and uninstalled the RTM public build of Nuget 2.0.  This fixed things and my extension can be found in VSExtension\bin\Release.  Double clicking this will install the custom Nuget build.

 

Option B: Stop Deploying on Build

You can actually turn off the deployment of your VSIX on build.  This might not be great for the build, debug story, but for this it worked great.image