Getting Your TFS Builds To Run Your Jasmine JavaScript Unit Tests
A month or so ago I was setting up an automated build and deployment using TFS 2013. I set my build up to run my unit tests, and to consider the build a failure if they didn't pass. If the build fails (either due to compilation failure or unit test failure), the deployment step shouldn't take place.
The application in question uses Angular.js and I've written a good number of unit tests to test my Angular controllers, services, etc. For these tests, I used Jasmine (instead of Karma, which is the most often recommended test framework for Angular -- long story). In Visual Studio, I make use of the awesome Chutzpah extension to allow my Jasmine unit tests to be integrated into the Test Explorer right-click context menu just like my MSTest unit tests of .NET code.
But how to get these to run as part of my automated build from TFS? It took a little digging, but thanks to an extremely helpful blog post and a little trial-and-error, I found the answer. Here's how:
1. Add Chutzpah to a folder in TFS (or whatever source control you're using) and set custom assemblies per the blog post at http://blogs.msdn.com/b/visualstudioalm/archive/2012/07/09/javascript-unit-tests-on-team-foundation-service-with-chutzpah.aspx. The post is a little out-of-date, but will take you most of the way there. It mentions a somewhat different list of files than I found in the most recent Chutzpah package, so I added all of the files from the Chutzpah package to the new folder in source control with the exception of those that would obviously have no impact (for example: documentation files).
2. Add a new test definition to your build, referencing the correct path to look for your .js tests from the build folder. It'll help if you have access to the build output directory to know what the correct path should be. This was something that the diagnostic log generated by TFS helped me troubleshoot ("Ah, I'm looking in the wrong path...")
3. Make sure the Chutzpah and Jasmine versions match on the developer and build machines. In my case, it turns out both went through an upgrade between the time I was developing my solution and the time I was setting things up on the build server! For example, I had to refactor some Jasmine code to account for some changes made in Jasmine 2.0 (spyOn() was one of the things that was affected).
I hope this helps you!
The application in question uses Angular.js and I've written a good number of unit tests to test my Angular controllers, services, etc. For these tests, I used Jasmine (instead of Karma, which is the most often recommended test framework for Angular -- long story). In Visual Studio, I make use of the awesome Chutzpah extension to allow my Jasmine unit tests to be integrated into the Test Explorer right-click context menu just like my MSTest unit tests of .NET code.
But how to get these to run as part of my automated build from TFS? It took a little digging, but thanks to an extremely helpful blog post and a little trial-and-error, I found the answer. Here's how:
1. Add Chutzpah to a folder in TFS (or whatever source control you're using) and set custom assemblies per the blog post at http://blogs.msdn.com/b/visualstudioalm/archive/2012/07/09/javascript-unit-tests-on-team-foundation-service-with-chutzpah.aspx. The post is a little out-of-date, but will take you most of the way there. It mentions a somewhat different list of files than I found in the most recent Chutzpah package, so I added all of the files from the Chutzpah package to the new folder in source control with the exception of those that would obviously have no impact (for example: documentation files).
2. Add a new test definition to your build, referencing the correct path to look for your .js tests from the build folder. It'll help if you have access to the build output directory to know what the correct path should be. This was something that the diagnostic log generated by TFS helped me troubleshoot ("Ah, I'm looking in the wrong path...")
3. Make sure the Chutzpah and Jasmine versions match on the developer and build machines. In my case, it turns out both went through an upgrade between the time I was developing my solution and the time I was setting things up on the build server! For example, I had to refactor some Jasmine code to account for some changes made in Jasmine 2.0 (spyOn() was one of the things that was affected).
I hope this helps you!
Comments
Post a Comment