Unit testing Angular service with HttpClient

Last Updated On

Table of contents

Foreword

Automated testing is one of the most important concepts that stand out Angular from the crowd of front-end Frameworks. Preconfigured test environment and out of the box working boilerplates make it even easier, to begin with. However, that's doesn't cover a case when your app needs to communicate with a server and that's what this article will be about. The main goal here is to show how to write unit tests for HttpClient - library that is used for "communication with backend" in Angular.

Before we start, let me briefly clarify what I mean by saying "testing".

Testing aside - What does that mean "test something"?

It is crucial to understand this concept when it comes to any type of testing (unit, integration, functional, performance and others). Hold on for a second and think about testing in general. Ironically, we do it many times a day. We just use different wording for that:

  • "Let me check that..."
  • "Can you please make sure that..."
  • "I need to verify that..."

What kind of sense do we put in those words? We want to ensure that our expectation is the same as the end result. For example, I want to check that I submit my report last week. What would I do? I'll go and check that it's inside the "Sent" folder, with a date in the past and there shouldn't be any failure. That's how I make sure that my email has been sent.

We compare one thing (expected result) with another one (actual result). That might be a really small piece, but very important one. Here's the definition: Testing is a comparison between the expected result and actual result. A test is passing if they're the same or failing if they're different. Therefore, it's impossible to write any type of test if we don't know expected result as there's nothing to compare to.

From now on, every time I will say test something (response, request or any other thing) I will mean compare one data with another and check if they are the same.

Testing strategy overview

After looking at testing aside, let's take a look at Angular specific details. Here, I want to highlight some concepts that will be used when testing Angular service:

1. Use HttpClient only inside Angular's service.

In other words not inside the component class. We want to isolate our "Data retrieving logic" from the view and be able to modify it without affecting the UI. Example: you have weather forecast app. Current weather provider suddenly stops working. We need to refactor our service to use the new data provider. So we will change our logic to be able to get data from a new server but keeping methods that are used by UI untouched. In other words, UI won't know about provider changes.

2. Mock Unit Tests with stubs.

To explain this concept I want you to imagine the following situation: Again, we work on a weather app, but in this case on a really huge and popular (like "Weather Underground"). The task is to test a function getWeatherInFahrenheit() which returns a value in a specific format. For example 70°F.

I wrote a unit test that goes to a server, gets the value and compares it to my expected value, e.g. 70°F. Let's assume that test passed. I added it to the common test suite and closed my task. Here'are few problems though:

  1. From now on this test will be run by every developer since it was added to the main test suite. If there're hundreds or more developers we will create unnecessary load on a data provider by asking data just for testing purposes.
  2. The main idea of the unit test is broken. Unit test supposes to test (as a name applies) individual unit. In this case, we added a dependency from a server. This is usually one of the problems that integration is solving - testing the communication between individual pieces inside the whole system.

Solution: We will introduce the concept of "Mock" (or stub). We will emulate response from a server by creating our own *.json file that will be the same as the response from a server.

Karma configuration

If the project you're working on has been initialized with Angular-CLI it will have karma.conf.js which is responsible for unit testing configuration. The content of that file contains the following:

// Karma configuration file, see link for more information
// https://karma-runner.github.io/1.0/config/configuration-file.html

module.exports = function (config) {
  config.set({
    ...
    browsers: ['Chrome'],
    ...
  });
};

This configuration requires to run a real browser and by default it's Chrome (since we have a line browsers: ['Chrome']). That might cause a problem if an application will be deployed to a server (since there's no GUI browser on a server). In addition to that, it might slow down the process of running unit tests.

The solution is to use "Headless" or command-line interface browser. It has the same functionality as a regular web browser, but doesn't require UI and can be executed in a terminal. There're few of these and the most popular solution was to use PhantomJS. However, nowadays there's more modern solution which is ChromeHeadless.

In order to use it we need to change only one line:

Replace browsers: ['Chrome'] with browsers: ['ChromeHeadless']. No extra packages needed.

First step - testing basic class

In this situation, it won't be even a service - just simple Typescript class. There's no problem with testing a class - just create an instance of it and call a method. Let's see what I mean by using a simple User class with one method:

export class User {
  private email: string;
  private password: string;

  constructor(email: string, password: string) {
    this.email = email;
    this.password = password;
  }

  public toJson() {
    return {
      email: this.email,
      password: this.password
    };
  }
}

Unit test for this class will look like:

import { User } from './user';
describe('User', () => {
  
  let user = null;

  /**
  * beforeEach will create fresh copy of User object
  * before each unit test. We also can define User object once 
  * and run unit tests against it, but in general it's a good practice
  * to work on a new instance of an object to avoid modifications from
  * the previous test run.
  */
  beforeEach(() => {
    user = new User('john@doe', 'johnspassword');
  });

  it('should be initialized', () => {
    expect(user).toBeTruthy();
  });
  it('should be serialized to Json properly', () => {
    const jsonPropertiesActual = Object.keys(user.toJson());
    const jsonPropertiesExpected = [
      'email',
      'password'
    ];
    expect(jsonPropertiesActual).toEqual(jsonPropertiesExpected);
  });
});

Second step - testing real Angular service

Here's an example of Angular service:

import { Injectable } from '@angular/core';
import { HttpClient, HttpHeaders } from '@angular/common/http';

@Injectable()
export class AuthService {
  constructor(private http: HttpClient) {}
}

Looks very similar to the first step. However, there is a pitfall here. Inside the constructor, there is an instance of httpClient which is created and fully managed by Angular. Behind the scenes, Angular makes sure that we will have only one instance of HttpClient across the whole application. As a result, we can not simply create a new instance of HttpClient and pass it to our service:

//...
//We can not do that, there will be an error
beforeEach(() => {
  const httpClient = new HttpClient();
  const authService = new AuthService(httpClient);
});

//...

As a solution we will "inject" it in Angular way. Here's how we do it:

import { TestBed, inject } from '@angular/core/testing';
import { HttpClientTestingModule } from '@angular/common/http/testing';
import { AuthService } from './auth.service';

describe('AuthService', () => {
  beforeEach(() => {
    TestBed.configureTestingModule({
      imports: [HttpClientTestingModule],
      providers: [AuthService]
    });
  });

  it('should be initialized', inject([AuthService], (authService: AuthService) => {
    expect(authService).toBeTruthy();
  }));
});

There're few new utilities here: TestBed, inject and HttpClientTestingModule.

  1. HttpClientTestingModule is analog of HttpClientModule, but for testing purposes.
  2. inject is Angular utility function that injects services into the test function. It takes two params: an array of services that we want to inject and instances of those services.
  3. TestBed.configureTestingModule is the same as @NgModule, but for test initialization.

Third Step - Add login to the service and write unit test for that

Let's add login method to our service. Here's how a final code will look:

import { Injectable } from '@angular/core';
import { HttpClient, HttpHeaders } from '@angular/common/http';
import { User } from '../models/user';
import { Observable } from 'rxjs/Observable';

@Injectable()
export class AuthService {
  private apiUrl = 'https://example.com/login';
  constructor(private http: HttpClient) {}

  public onLogin(user: User): Observable<Object> {
    return this.http.post(this.apiUrl, user);
  }
}

And here's a complete unit test for that:

import { TestBed, inject } from '@angular/core/testing';
import {
  HttpClientTestingModule,
  HttpTestingController
} from '@angular/common/http/testing';
import { AuthService } from './auth.service';
import { User } from '../models/user';

describe('AuthService', () => {
  beforeEach(() => {
    TestBed.configureTestingModule({
      imports: [HttpClientTestingModule],
      providers: [AuthService]
    });
  });

  it(
    'should be initialized',
    inject([AuthService], (authService: AuthService) => {
      expect(authService).toBeTruthy();
    })
  );

  it(
    'should perform login correctly',
    inject(
      [AuthService, HttpTestingController],
      (authService: AuthService, backend: HttpTestingController) => {
        const user = new User('test@example.com', 'testpassword');
        authService.onLogin(user).subscribe(
          (data: any) => {
            expect(data.success).toBe(true);
            expect(data.message).toBe('login was successful');
          },
          (error: any) => {}
        );

        backend
          .expectOne({
            url: 'https://example.com/login'
          })
          .flush({
            success: true,
            message: 'login was successful'
          });
      }
    )
  );

  it(
    'should fail login correctly',
    inject(
      [AuthService, HttpTestingController],
      (authService: AuthService, backend: HttpTestingController) => {
        const user = new User('test@example.com', 'wrongPassword');
        authService.onLogin(user).subscribe(
          (data: any) => {
            expect(data.success).toBe(false);
            expect(data.message).toBe('email and password combination is wrong');
          },
          (error: any) => {}
        );

        backend
          .expectOne({
            url: 'https://example.com/login'
          })
          .flush({
            success: false,
            message: 'email and password combination is wrong'
          });
      }
    )
  );
});

In this unit test, we can see a new concept of HttpTestingController which is named as a backend. Basically, it watches the URL which will be called, intercepts it and returns a "fake" response. From the example above you can see the API where we pass an object that contains URL to intercept and then flush it with "fake" response. In addition to expectOne, there're other methods like match, expectNone and verify. You can find more information about them in the official documentation.

Live demo

Here's the live example of this demo. Combination test@example.com, testpassword is correct and any other combination is wrong.

Conclusion

Being able to verify every little piece of your functionality is very important when adding new features, enhancing your current functionality or simply refactoring your code. In this article, we covered what testing is, how to write a basic test for Angular and how to test service with HttpClient as a dependency injection. I would recommend playing on your own, try different technics and move to the next level by using TDD.

As always, this article is aimed to give you a basic idea how to quickly start when testing HttpClient for Angular. For more details, please take a look at the official documentation.