When I started developing and writing tests for Angularjs applications, everything felt natural. The tools were mature and I easily got used to developing applications in TDD (Test-Driven Development). It gave me a high level of confidence, knowing that my application was working as I had imagined. Just after Angular 2 came out and I learned the basics, I knew that the next step was to testing.

This article is the first part of a series in which I share my experiences testing different building blocks of an Angular 2 application. We will start with simple use cases and then head for more complex ones.

• Services (this article)
• Http Services
• Components
• Pipes
• Routing

You may wonder why it is so important to write tests.

With tests, we can ensure the correctness of our application: that the code does what it was designed to do. We can guard against someone breaking our code by refactoring or adding new features. This might have happened to you when someone added a small feature or equivalent code transformations and nothing worked afterward. Writing tests can clarify the intention of the code by giving usage examples. It can also reveal design flaws. When a piece of code is hard to test, there might be a problem with the underlying architecture.

If you are new to Test-Driven Development, I would recommend reading the Test-Driven Development book by Kent Beck. It gives a nice overview about the concepts and best practices.

Choosing the Framework to Test Angular 2

The first thing we have to choose is the framework. The one suggested by Angular 2's core team is Jasmine. For a long time, it was the only supported testing framework, because test setups were hard wired into the framework. Thanks to refactoring, now tests can also be written in Mocha, or any other framework that supports the beforeEach hook. This hook runs before every test run. If your framework of choice doesn't support it, you have to add the following code snippet to your setup:

import { resetFakeAsyncZone, TestBed } from '@angular/core/testing';

beforeEveryTestHook(() => {
  TestBed.resetTestingModule();
  resetFakeAsyncZone();
});

The first line within the hook resets the internal state of the Dependency Injection container. It clears out any given provider or module. If you are not familiar with Dependency Injection, I would recommend reading the official documentation about it.

The second one clears out any remaining zone that fakes asynchronous operations like setTimeout. Detailed articles can be found on the Thoughtram blog about zones: Understanding zones and Zones in Angular 2.

For this series, we will be using Jasmine as the test framework.

Writing the First Angular 2 Test

Let's look at our first service that will be tested.

import { Injectable } from '@angular/core';

@Injectable()
export class Engine {
  getHorsepower() {
    return 150;
  }

  getName() {
    return 'Basic engine';
  }
}

It has two getter methods and the Injectable decorator. The tests will check whether these getter methods work as intended. The decorator is needed to utilize dependency injection.

In Jasmine, we can group our tests with the describe method. Within this method, we can create test cases with the it function. It is advised to place one class per file (the service) and group the tests around it (with describe). We can further group test cases around methods of the class by placing describe statements inside the top describe block. For now, we will only group our tests around the class.

import { Engine } from './engine.service';

describe('Engine', () => {
  it('should return it\'s horsepower', () => {
    let subject = new Engine();

    expect(subject.getHorsepower()).toEqual(150);
  });
});

In this setup, only plain instantiation is used; we will introduce dependency injection later. For basic services, plain instantiation can be enough.

We call the getHorsepower method of the engine and check that it's equal to the expected value.

The first test is green and has been passed. Let's write another one for the getName method.

it('should return it\'s horsepower', () => {
  let subject = new Engine();

  expect(subject.getName()).toEqual('Basic engine');
});

If you run the tests, a similar output will be on the terminal.

Both tests have been passed; it is time to refactor. There is duplication at the start of each Angular 2 test. Instantiation is exactly the same, we can move it out into a setup block.

describe('Engine', () => {
  let subject: Engine;

  beforeEach(() => {
    subject = new Engine();
  });

  it('should return it\'s horsepower', () => {
    expect(subject.getHorsepower()).toEqual(150);
  });

  it('should return it\'s horsepower', () => {
    expect(subject.getName()).toEqual('Basic engine');
  });
});

The subject variable is declared at the start of the describe block, and the creation of the service is moved to the beforeEach block. This way we don't have to do it manually every time. It is common to move the creation of the test case subject to a separate method, because it offloads the tests and makes them more readable.

Using Dependency Injection

Creating services directly can be good if the subject under test has no or few, dependencies. But if it has multiple dependencies, or a deeper dependency tree, setting up all the classes becomes tedious. For these situations, we can use Angular 2's dependency injection management.

The Car class uses the Engine class in the constructor and its instance in the getName method.

import { Injectable } from '@angular/core';
import { Engine } from './engine.service';

@Injectable()
export class Car {
  constructor(private engine: Engine) {}

  getName() {
    return `Car with ${this.engine.getName()}(${this.engine.getHorsepower()} HP)`;
  }
}

We check for the getName method's output in the test after we set up the dependency injection container.

import { TestBed, inject } from '@angular/core/testing';
import { Engine } from './engine.service';
import { Car } from './car.service';

describe('Car', () => {
  let subject: Car;

  beforeEach(() => {
    TestBed.configureTestingModule({
      providers: [Engine, Car]
    });
  });

  beforeEach(inject([Car], (car: Car) => {
    subject = car;
  }));

  it('should display name with engine', () => {
    expect(subject.getName()).toEqual('Car with Basic engine(150 HP)');
  });
});

The difference here is that we configure the TestBed with the provided services in the configureTestingModule method. Only these classes can be instantiated with the inject method. If we try to request something else, we get an error saying it is an unknown provider.

We can request instances of the services in an array from the inject method. In the callback, we get the instances in the same order as in the dependency array with the first parameter. The type hint inside the callback is only for IDE completion; it also works without it. In the example, it is placed inside the beforeEach function, but it can also be added to the it block.

it('should display name with engine', inject([Car], (car: Car) => {
  expect(car.getName()).toEqual('Car with Basic engine(150 HP)');
}));

Mocking

In unit tests for Angular 2, we want to execute the code in isolation. This means it is not dependent on big, complex objects and is not calling methods that rely on external systems (like HTTP calls or database access). In these cases, we want to simulate the original behavior while skipping the underlying implementation.

When achieved, it is called mocking. We don't have to do it manually. Jasmine provides tools to make it work. Let's assume that the method of the Engine class has a call through to the server and we want to mock it.

...
beforeEach(() => {
  TestBed.configureTestingModule({
    providers: [Engine, Car]
  });

  spyOn(Engine.prototype, 'getHorsepower').and.returnValue(400);
  spyOn(Engine.prototype, 'getName').and.returnValue('V8 engine');
});

...

it('should display name with engine', () => {
  expect(subject.getName()).toEqual('Car with V8 engine(400 HP)');
});

We mock the class methods by calling the spyOn method on the class's prototype. We also alter the return value of the function. This way the original method never gets called. When mocking the prototype, it affects every instance of the class.

Using Dependency Injection for Mocking

The previous solution for mocking can be achieved also with Angular 2's dependency injection mechanism. We pass the Engine class as the provider token, but create the instances with a fake class.

@Injectable()
class V8Engine {
  getHorsepower() {
    return 400;
  }

  getName() {
    return 'V8 engine';
  }
}

Then we pass this fake class to the setup.

beforeEach(() => {
  TestBed.configureTestingModule({
    providers: [
      { provide: Engine, useClass: V8Engine },
      Car
    ]
  });
});

With this setup, the inject call will return an instance of V8Engine when asked for Engine. We can also use useFactory with a callback, or useValue with an instance, to accomplish the same result. The only drawback here is that every method of the class must be implemented and changed whenever the original class changes. The original class can be extended optionally in order to override only specific methods.

What We've learned about Angular 2 Testing

In this tutorial, we managed to:

• create a basic service and write tests for it
• use dependency injection in tests
• fake dependencies with Jasmine
• fake dependencies with dependency injection

If you follow the steps introduced in this article and write tests for your Angular 2 application, you can sleep safe and sound. The code will work as intended and when someone accidentally breaks it, the tests will warn him that those changes are unsafe and shouldn't be committed until the tests are green again.

Jasmine will help you along the way with its easy syntax and batteries included (assertion and mocking library).

I hope this has convinced you that writing tests in Angular 2 is not an overly complicated thing.

To make the start even easier, the code is available in this GitHub repository.