Going off piste
That's the disclaimers out of the way now...
...Try, try, try again...
So after a number of failed attempts I’m going to give it another go. Rushaine McBean says Jasmine is easiest so I'm going to follow her lead and give it a go.
As well it might. I’d be worried if it didn’t. So I’ll move the contents of the release package into my empty project. Now let’s see if we can get those tests running inside Visual Studio. I’d heard of Chutzpah which describes itself thusly:
What I’m after is the Chutzpah test adapter for Visual Studio 2012/2013 which can be found here. I download the VSIX and install. Pretty painless. Once I restart Visual Studio I can see my unit tests in the test explorer. Nice! Run them and...
All fail. This makes me sad. All the errors say “Can’t find variable: Player in file”. Hmmm. Why? Dammit I’m actually going to have to read the documentation... It turns out the issue can be happily resolved by adding these 3 references to the top of PlayerSpec.js:
/// <reference path="../src/Player.js" /> /// <reference path="../src/Song.js" /> /// <reference path="SpecHelper.js" />
Now the tests pass:
The question is: can we get this working with Visual Studio Online?
Back to Mathew's blog. It suggests renaming Chutzpah.VS2012.vsix to Chutzpah.VS2012.zip and checking certain files into TFS. I think Chutzpah has changed a certain amount since this was written. To be on the safe side I’ll create a new folder in the root of my project called Chutzpah.VS2012 and put the contents of Chutzpah.VS2012.zip in there and add it to TFS (being careful to ensure that no dll’s are excluded).
Then I'll follow steps 3 and 4 from the blog post:
3. In Visual Studio, Open Team Explorer & connect to Team Foundation Service.
Bring up the Manage Build Controllers dialog. [Build –> Manage Build Controllers]
Select Hosted Build Controller
Click on Properties button to bring up the Build Controller Properties dialog.
4. Change Version Control Path to custom Assemblies to refer to the folder where you checked in the binaries in step 2.
In step 5 the blog tells me to edit my build definition. Well I don’t have one in this new project so let’s click on “New Build Definition”, create one and then follow step 5:
Click on the Process tab
Select the row named Automated Tests.
Click on … button next to the value.
Rather than following step 6 (which essentially nukes the running of any .NET tests you might have) I chose to add another row by clicking "Add". In the dialog presented I changed the Test assembly specification to **\*.js and checked the "Fail build on test failure" checkbox.
Step 7 says:
7. Create your Web application in Visual Studio and add your Qunit or Jasmine unit tests to them. Make sure that the js files (that contain the tests) are getting copied to the build output directory.
The picture below step 7 suggests that you should be setting your test / spec files to have a
Copy to Output Directory setting of
Copy always. This did not work for me!!! Instead, setting a
Build Action of
Content and a
Copy to Output Directory setting of
Do not copy did work.
Finally I checked everything into source control and queued a build. I honestly did not expect this to work. It couldn’t be this easy could it? And...
Wow! It did! Here’s me cynically expecting some kind of “permission denied” error and it actually works! Brilliant! Look up in the cloud it says the same thing!
Having got up and running off the back of other peoples hard work I best try and write some of my own tests now....