Automated Angular Unit Testing on Visual Studio Team Services

Fredrik Lundin
5 min readAug 17, 2017

--

Introduction

One of the key selling points for Angular is how it’s really built to be testable. And while it indeed might take some effort to wrap your head around the extensive testing tools that comes with the framework, it really is powerful!

In this article I will explain how to setup your Angular CLI project and Visual Studio Team Services (VSTS) build configuration to run all your unit test on every build!

This guide will assume that you have an Angular CLI application already setup to run on VSTS. If you need help with that, please take a look at my other post: Setting up a CI pipeline for deploying your Angular application to Azure using Visual Studio Team Services and GitHub

Steps we will take

  1. Install PhantomJS to our project
  2. Prepare our NPM Test script
  3. Add the necessary Polyfills
  4. Add a Test and Publish Test Result Build Step on VSTS
  5. Add a necessary Process Variable

PhantomJS

By default, new CLI projects are configured to run test with the Karma test runner. And the default Karma configuration is setup to execute that tests on the Chrome browser.

Since the test we write for our Angular applications often includes interacting with DOM elements, we need a browser to execute the tests on. And the default choice, Chrome, works fine when we do it on our own machines. The problem arise when we ask Karma to run our test on Chrome on a build server that is unable to spawn a Chrome process. What we really want to do is to be able run our test in a console without a browser. PhantomJS for the rescue!

PhantomJS is a so called Headless Browser (or headless WebKit scriptable, as they call it themselves). A headless browser is a browser that is just running in the background, that you can only interact with via code or a terminal. This is just what we need, so let’s make our test run on Phantom instead of Chrome.

Install these three packages:

phantomjs-prebuilt contains the executable for the headless browser.
karma-phantomjs-launcher is, well, a launcher that Karma needs to be able to run tests on the phantom browser.
karma-junit-reporter is another plugin for Karma that will allow us to get the test output in an XML format so that VSTS can present it for us nicely. More on that later!

With the necessary packages in place, we need to make some changes to our karma configuration file. In karma.conf.js, make the following three additions:

NPM Test Script

Okey, now we have have PhantomJS installed, but still no way of running the tests with it. All we have to do in order to solve that is to add a new test script to our script section in our package.json file. The new script will specifically instructs Karma what browser we want it to execute our tests in. Here is the script we will add:

ng test is simply for running tests.
— single-run=true is for just running the tests just once instead of watching the files for changes and keep executing them (which is usually what we want while developing).
— browsers=PhantomJS is for telling Karma to to execute the test in PhantomJS
— reporters=progress,junit tells Karma to Report (output) test results via progress (terminal) and junit (XML)

Additional Polyfills

As we all know, browser support and JavaScript compatibility is hard and boring. Luckily, polyfills can take us a long way with helping out with these issues. A polyfill, for those who don’t know, is kind of like a fallback, written in JavaScript, for browsers that don’t already support certain features that our application code expects it too. In that way, we can add support of some new browser features to older browsers!

When you scaffold an Angular CLI application, the CLI will create a file called polyfills.ts for you automatically. Most lines in that file will be commented out by default, so it’s up to each and every developer to decide what polyfills he or she needs or want to include in their applications. The reason for not including everything by default is obviously to keep the size of the application to a minimum.

Anyways, to get our test running properly in PhantomJS we need to uncomment (include) these three lines:

Adding Testing to the VSTS Build Pipeline

I will not go into nitty-gritty details on adding build steps in VSTS, as this is covered in my previous post in the series (link at top). But essentially, we will add two more steps, modify an existing one and add a process variable.

Runs tests will be another npm script task that will execute the command run with the arguments test-single-headless, which is the npm script we added to our package.json earlier.

run tests

Publish Test Results is the task we will use for visualizing the test results we get. See the image bellow for the parameters. Note that we set the Control Option to run this step even if the previous step fails or the build was cancelled. This way we will be able to display even failed tests.

Publish Test Results

Make sure that the actual Build tasks is set to NOT run if previous tasks failed. We do this to ensure that we only continue with the build while all tests succeed.

Build task

Adding a process variable to PhantomJS.cmd

Finally, we need to add a process variable that points to the executable file needed for VSTS to run PhantomJS. We do this under the Variables tab, like this:

Process variable

That should be it!

Now your tests should be running every time a new build is triggered on VSTS. And thanks to the Publish Test Results task, you will be able to see a nice dashboardy visualization of your build. It could look something like this:

Build results

Note how the build and publish steps on the image above were never run, as one of the tests failed.

I hope this was helpful. If anything is unclear, feel free to drop a comment in the comments section below or hit me up on twitter!

--

--

Fredrik Lundin

twitter: @kirderfLundin — Developer working for Active Solution in Stockholm, Sweden