How to Unit Test Services

The first thing we will start with is learning how to unit test very simple services. These might be services without any dependencies that act as encapsulators of business logic or functionality that needs to be reused across our application.

We will start with testing the very simple service we built in Chapter 8. You can use the codebase in chapter8/simple-service as the base for this section. The finished code is available in chapter10/simple-service.

Any time we are unit testing our service, we must do a few things over and above what we did for testing components. Namely:

• Configure the Angular TestBed with a provider for the service we want to test.

• Inject an instance of the service we want to test either into our test or as a common instance in the beforeEach.

When you generate a service using the Angular CLI, this initial skeleton is generated for you out of the box. Regardless, let’s first take a look at the skeleton spec that was generated in src/app/services/stock.service.spec.ts:

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

import { StockService } from './stock.service';

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

  it('should be created', inject([StockService],
      (service: StockService) => {
    expect(service).toBeTruthy();
  }));
});

The basic skeleton itself allows us to walk through some of the initial setup that we mentioned. Let’s cover the most important bits:

• In the beforeEach, like we used to register the components, we now register the provider for the StockService. This ensures that the test is now running in the context of our testing module.

• In the it, which is the actual test, instead of just passing the test function to it, we call inject, which is a function provided by the Angular testing utilities. We pass an array to it as the first argument, which are the Angular services that need to be injected into our test. The second argument is a function that gets the arguments in the same order that we passed to the array. We write our actual test within this function.

In the skeleton code, we instantiate the StockService provider with the testing module, and then just make sure that when we inject it in the test, we get an instantiated version of the service for use in the test.

Before we get on to the actual test, let’s quickly review the service that we will be testing. The StockService currently looks like the following:

import { Injectable } from '@angular/core';
import { Stock } from 'app/model/stock';

@Injectable()
export class StockService {

  private stocks: Stock[];
  constructor() {
    this.stocks = [
      new Stock('Test Stock Company', 'TSC', 85, 80, 'NASDAQ'),
      new Stock('Second Stock Company', 'SSC', 10, 20, 'NSE'),
      new Stock('Last Stock Company', 'LSC', 876, 765, 'NYSE')
    ];
   }

  getStocks() : Stock[] {
    return this.stocks;
  }

  createStock(stock: Stock) {
    let foundStock = this.stocks.find(each => each.code === stock.code);
    if (foundStock) {
      return false;
    }
    this.stocks.push(stock);
    return true;
  }

  toggleFavorite(stock: Stock) {
    let foundStock = this.stocks.find(each => each.code === stock.code);
    foundStock.favorite = !foundStock.favorite;
  }
}

The StockService has three stocks that are instantiated by default. When we call getStocks(), this list of three stocks is returned. We can also add stocks by calling createStock, which checks for the presence of the stock and then adds it.

Now let’s improve it to actually test the service, which had the capability of getting a list of stocks and adding stocks. We will add two tests for these two methods:

/** Other imports skipped for brevity **/
import { Stock } from 'app/model/stock';

describe('StockService', () => {
  var stockService: StockService;
  beforeEach(() => {
    /** No change in first beforeEach, skipping for brevity **/
  });

  beforeEach(inject([StockService],             
    (service: StockService) => {
      stockService = service;
  }));

  it('should allow adding stocks', () => {
    expect(stockService.getStocks().length).toEqual(3);      
    let stock = new Stock('Testing A New Company', 'TTT',
        850, 800, 'NASDAQ');
    expect(stockService.createStock(stock)).toBeTruthy();    
    expect(stockService.getStocks().length).toEqual(4);      
    expect(stockService.getStocks()[3].code).toEqual('TTT')
  });

  it('should fetch a list of stocks', () => {
    expect(stockService.getStocks().length).toEqual(3);      
    expect(stockService.getStocks()[0].code).toEqual('TSC'); 
    expect(stockService.getStocks()[1].code).toEqual('SSC');
    expect(stockService.getStocks()[2].code).toEqual('LSC');
  });
});

Inject StockService into another beforeEach and save it for access across tests

Ensure that we start with the original three stocks from our service

Add the stock and ensure that it returns true

Check for the presence of the stock we added in the service

Ensure that we start with the original three stocks from our service

Check each stock to ensure it is the data we expect

We have made a slight change to the initialization logic, and added two pretty mundane, run-of-the-mill tests:

• Instead of writing an inject block in each test (each it block), we have moved that logic to another beforeEach block, which is solely responsible for setting up local variables that will be repeatedly used across all the tests. Note that this does not mean the same instance is used in all the tests, but that we don’t have to inject the service into each test individually.

• We have added two tests, one to test adding of stocks and another to check the default getStocks() call. Again, note that the two tests are independent. Our adding a stock in the first stock does not result in there being four stocks in the second test. Before each test, we are creating a new testing module with a new instance of the service.

Other than this, the test itself is pretty straightforward and self-explanatory. To run this test, simply execute:

ng test

That should automatically start Karma, capture Chrome, run the tests, and report the results right in your terminal window.

Testing Components with a Service Dependency

Next, let’s see how to deal with two slightly different situations:

• If we had to test a component, and actually use the real service underneath in the test.

• If we had to test a component, and we wanted to mock out the service it depends on in the test.

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

import { StockListComponent } from './stock-list.component';
import { StockService } from 'app/services/stock.service';
import { StockItemComponent } from 'app/stock/stock-item/stock-item.component';
import { Stock } from 'app/model/stock';

describe('StockListComponent With Real Service', () => {
  let component: StockListComponent;
  let fixture: ComponentFixture<StockListComponent>;

  beforeEach(async(() => {
    TestBed.configureTestingModule({
      declarations: [ StockListComponent, StockItemComponent ],    
      providers: [ StockService ]                                  
    })
    .compileComponents();
  }));

  beforeEach(() => {
    fixture = TestBed.createComponent(StockListComponent);
    component = fixture.componentInstance;
    fixture.detectChanges();
  });

  it('should load stocks from real service on init', () => {
    expect(component).toBeTruthy();
    expect(component.stocks.length).toEqual(3);                   
  });
});

/** Standard imports, skipping for brevity **/

describe('StockListComponent With Mock Service', () => {
  let component: StockListComponent;
  let fixture: ComponentFixture<StockListComponent>;
  let stockService: StockService;

  beforeEach(async(() => {
    /** No change in TestBed configuration, skipping for brevity **/
  }));

  beforeEach(() => {
    fixture = TestBed.createComponent(StockListComponent);
    component = fixture.componentInstance;
    // Always get the Service from the Injector!
    stockService = fixture.debugElement.injector.get(StockService);   
    let spy = spyOn(stockService, 'getStocks')                        
        .and.returnValue([
          new Stock('Mock Stock', 'MS', 800, 900, 'NYSE')
        ]);
    fixture.detectChanges();
  });

  it('should load stocks from mocked service on init', () => {
    expect(component).toBeTruthy();
    expect(component.stocks.length).toEqual(1);                       
    expect(component.stocks[0].code).toEqual('MS');
  });
});

/** Skipping imports for brevity **/

describe('StockListComponent With Fake Service', () => {
  let component: StockListComponent;
  let fixture: ComponentFixture<StockListComponent>;

  beforeEach(async(() => {
    let stockServiceFake = {                           
      getStocks: () => {
        return [new Stock('Fake Stock', 'FS', 800, 900, 'NYSE')];
      }
    };
    TestBed.configureTestingModule({
      declarations: [ StockListComponent, StockItemComponent ],
      providers: [ {
        provide: StockService,
        useValue: stockServiceFake                        
      } ]
    })
    .compileComponents();
  }));

  beforeEach(() => {
    fixture = TestBed.createComponent(StockListComponent);
    component = fixture.componentInstance;
    fixture.detectChanges();
  });

  it('should load stocks from fake service on init', () => {
    expect(component).toBeTruthy();
    expect(component.stocks.length).toEqual(1);
    expect(component.stocks[0].code).toEqual('FS');         
  });
});

Unit Testing Async

So far, we have seen how we might test simple and straightforward services, with or without further dependencies, as well as test components. But the services we have worked with so far have been synchronous. In this section, we will dig a little bit into how to handle and write tests when the underlying service or code deals with asynchronous flows.

With any code that touches an asynchronous flow, we have to be careful in our tests and recognize at which point the hand-off happens from synchronous flow to asynchronous, and deal with it accordingly. Thankfully, Angular provides enough helpers to abstract out some of the complexities of this in our test.

Fundamentally, we have to make sure our test itself is identified and running as an asynchronous test. Secondly, we must ensure that we identify when we have to wait for the asynchronous part to finish, and validate the changes after that.

Let’s see how a test for the CreateStockComponent might look, when we had just switched to using observables (but not HTTP yet). We will use the codebase from chapter8/observables as the base on which to write our tests.

We will add (or modify if the skeleton already exists) the src/app/stock/create-stock/create-stock.component.spec.ts file, and change it as follows:

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

import { CreateStockComponent } from './create-stock.component';
import { StockService } from 'app/services/stock.service';
import { Stock } from 'app/model/stock';
import { FormsModule } from '@angular/forms';
import { By } from '@angular/platform-browser';


describe('CreateStockComponent', () => {
  let component: CreateStockComponent;
  let fixture: ComponentFixture<CreateStockComponent>;

  beforeEach(async(() => {
    TestBed.configureTestingModule({
      declarations: [ CreateStockComponent ],
      providers: [ StockService ],
      imports: [ FormsModule ]         
    })
    .compileComponents();
  }));

  beforeEach(() => {
    fixture = TestBed.createComponent(CreateStockComponent);
    component = fixture.componentInstance;
    fixture.detectChanges();
  });

  it('should create stock through service', async(() => {   
    expect(component).toBeTruthy();
    component.stock = new Stock(
      'My New Test Stock', 'MNTS', 100, 120, 'NYSE');

    component.createStock({valid: true});

    fixture.whenStable().then(() => {        
      fixture.detectChanges();               
      expect(component.message)
          .toEqual('Stock with code MNTS successfully created');
      const messageEl = fixture.debugElement.query(
          By.css('.message')).nativeElement;
      expect(messageEl.textContent)
          .toBe('Stock with code MNTS successfully created');
    });
  }));
});

The CreateStockComponent needs FormsModule to work

Pass the return value of calling async as the second param to the it function

Wait for the test fixture to finish executing asynchronous flows

Update the view after the changes

The early part of the unit test remains pretty much the same, from initializing the TestBed with the module to the beforeEach. We also have to import the FormsModule for the CreateStockComponent to work.

The first difference comes in the it declaration itself of our asynchronous test. Instead of simply passing the function containing our test code to the it block, we now pass an async function, which in turn is passed the function containing our test code. Do not forget this part when writing an asynchronous unit test.

The second major difference is after calling the function under test, createStock(), which actually triggers the asynchronous flow. Normally, we would write our assertions right after this. In the case of an asynchronous flow, we need to ask Angular’s test fixture to stabilize (that is, wait for the asynchronous parts to finish). The whenStabilize returns a promise that on completion allows us to run the remaining part of the test. In this case, we tell Angular to detect any changes and update the UI, and then make our assertions.

The finished code for this example is available in the chapter10/observables folder in the GitHub repository.

Unit Testing HTTP

The last thing we will take a look at in this chapter is to see how to test HTTP communication. In particular, we will dig into how to mock out server calls. We will see how to leverage Angular’s built-in testing utilities that it provides to test HTTP communication.

For this section, we will use the code from chapter9/simple-http as the base, and see how we can test both GET calls like fetching a list of stocks as well as POST calls that we make to create stocks.

First, let’s test the StockListComponent to see how we can test the initialization logic of fetching the list of stocks from our server. We want to ensure the entire flow of making a server call, getting the list of stocks, and then displaying it.

We will modify src/app/stock/stock-list/stock-list.component.spec.ts as follows:

/** Standard imports, skipping for brevity **/

import { HttpClientModule } from '@angular/common/http';
import { HttpClientTestingModule, HttpTestingController }
    from '@angular/common/http/testing';
import { By } from '@angular/platform-browser';


describe('StockListComponent With Real Service', () => {
  let component: StockListComponent;
  let fixture: ComponentFixture<StockListComponent>;
  let httpBackend: HttpTestingController;      

  beforeEach(async(() => {
    TestBed.configureTestingModule({
      declarations: [ StockListComponent, StockItemComponent ],
      providers: [ StockService ],
      imports: [
        HttpClientModule,
        HttpClientTestingModule                
      ]
    })
    .compileComponents();
  }));

  beforeEach(inject([HttpTestingController],
      (backend: HttpTestingController) => {
    httpBackend = backend;
    fixture = TestBed.createComponent(StockListComponent);
    component = fixture.componentInstance;
    fixture.detectChanges();
    httpBackend.expectOne({                   
      url: '/api/stock',
      method: 'GET'
    }, 'Get list of stocks').flush([{         
      name: 'Test Stock 1',
      code: 'TS1',
      price: 80,
      previousPrice: 90,
      exchange: 'NYSE'
    }, {
      name: 'Test Stock 2',
      code: 'TS2',
      price: 800,
      previousPrice: 900,
      exchange: 'NYSE'
    }]);
  }));

  it('should load stocks from real service on init',
      async(() => {
    expect(component).toBeTruthy();
    expect(component.stocks$).toBeTruthy();

    fixture.whenStable().then(() => {         
      fixture.detectChanges();
      const stockItems = fixture.debugElement.queryAll(
        By.css('app-stock-item'));
      expect(stockItems.length).toEqual(2);
    });
  }));

  afterEach(() => {
    httpBackend.verify();                  
  });
});

Include the HttpTestingController as a local variable

Import the HttpClientModule and the HttpTestingController in the module

Set expectation that one call to /api/stock will be made as part of the test

Define a list of hardcoded stocks to return when the GET call is made

Wait for the Angular task queue to get empty, and then proceed

Verify that the GET call to /api/stock was actually made as part of the test

While the test seems very long, the changes to support testing HTTP calls are actually pretty straightforward. The major change when it comes to writing tests for code that makes XHR calls is the use of the HttpTestingController. In our unit test, while we want to test the code flow that makes XHR calls, we don’t really want to make the actual underlying call. Any network call in a test adds unreliable dependencies, and makes our tests brittle and possibly nondeterministic.

For this reason, we actually mock out the XHR calls in our tests, just check that the right XHR calls are made, and that if the response was a certain value, then it is handled correctly. Therefore, a lot of our tests would simply be setting up through the HttpTestingController what calls to expect and what responses to send when those calls are made. You even have control over whether the server responds with a 200 success response, or whether it is an error (a 400 or 500 response, which corresponds to a client- or server-side error, respectively).

With that context, let’s walk through the points of interest in the preceding test:

1. The first and most important change is that we need to import the HttpClientModule so that our service can initialize with the injected HttpClient.

2. The second thing is that we include the HttpClientTestingModule from @angular/common/http/testing. This testing module helps automatically mock out the actual server calls, and replaces it with a HttpTestingController that can intercept and mock all server calls.

3. We hook these two modules up in the imports section of the TestBed module configuration.

4. Then in our test (or in this case, the beforeEach), we can inject an instance of the HttpTestingController to set our expectations and verify server calls.

5. After initializing the component instance as usual, we then start setting our expectations on the HttpTestingController. In this case, we expect that one GET call to the URL /api/stock. We also pass it a human-readable text to print in the logs in case the test fails or that call is not made.

6. In addition to setting expectations on calls made, we can also define the response Angular should send when those calls are made. Here, we return an array of two stocks by calling the flush method. The first argument to flush is the response body.

7. The rest of the test is straightforward. We expect the component to be initialized. Then, we wait for the change detection to stabilize (by calling fixture.whenStable()), and then ensure that the response we returned is actually rendered in the template correctly.

8. In the afterEach, we call httpBackend.verify(). This ensures that all the expectations we set on the HttpTestingController were actually satisfied during the run of the test. It is generally good practice to do this in the afterEach, to ensure that our code doesn’t make extra or fewer calls.

Let’s quickly write one more test to see how to handle POST calls, and how to send non-200 responses from the server. We will create the src/app/stock/create-stock/create-stock.component.spec.ts file as follows:

/** Standard imports, skipping for brevity **/

describe('CreateStockComponent With Real Service', () => {
  let component: CreateStockComponent;
  let fixture: ComponentFixture<CreateStockComponent>;
  let httpBackend: HttpTestingController;

  beforeEach(async(() => {
    /** TestBed configuration similar to before, skipping for brevity **/
  }));

  beforeEach(inject([HttpTestingController],
      (backend: HttpTestingController) => {
    httpBackend = backend;
    fixture = TestBed.createComponent(CreateStockComponent);
    component = fixture.componentInstance;
    fixture.detectChanges();
  }));

  it('should make call to create stock and handle failure',
      async(() => {
    expect(component).toBeTruthy();
    fixture.detectChanges();

    component.stock = {
      name: 'Test Stock',
      price: 200,
      previousPrice: 500,
      code: 'TSS',
      exchange: 'NYSE',
      favorite: false
    };

    component.createStock({valid: true});

    let httpReq = httpBackend.expectOne({        
      url: '/api/stock',
      method: 'POST'
    }, 'Create Stock with Failure');
    expect(httpReq.request.body).toEqual(component.stock);    
    httpReq.flush({msg: 'Stock already exists.'},         
        {status: 400, statusText: 'Failed!!'});

    fixture.whenStable().then(() => {
      fixture.detectChanges();
      const messageEl = fixture.debugElement.query(
          By.css('.message')).nativeElement;
      expect(messageEl.textContent).toEqual('Stock already exists.');   
    });
  }));

  afterEach(() => {
    httpBackend.verify();           
  });
});

Expect a POST request to be made to /api/stock during the test

Ensure that the body of the POST request is the same as the stock we created in the component

Define the response for the POST request, which is a failure 400 response

Check that the server response is shown correctly by the component

Ensure that the POST request happened during the test

Most of the preceding test should be very similar to the test we wrote for the StockListComponent. Let’s talk about the major differences in detail:

• Instead of immediately flushing the response when we set the expectation on the httpBackend for the POST call, we save it to a local variable.

• We can then write expectations on the various parts of the HTTP request, like the method, URL, body, headers, and so on.

• We then ensure that the body of the request matches the stock in our component.

• Finally, we flush a response, but instead of just flushing the body, we pass a second options argument to configure the response further. We mark the response as a 400 response to trigger the error condition.

• The rest of the test doesn’t change, from waiting for the fixture to stabilize, asserting on the elements, to verifying that the calls were made on the httpBackend.

The finished code is available in the chapter10/simple-http folder of the GitHub repository.

Conclusion

In this chapter, we dug deeper into testing services in Angular. We looked at how we could test services, as well as components that use services. We explored the various techniques and options to deal with services, from using the real service, to mocking it or stubbing it out. Then we moved onto seeing how we could handle async behavior when it came to unit tests, and then finally how to deal with XHR and HTTP in our tests.

In the next chapter, we will switch back to seeing how we can enhance our Angular applications with the ability to deep-link to certain pages and components. We will see how to start setting up our routes, as well as protect certain routes to be accessible under only certain conditions.

Exercise

Take the finished exercise from Chapter 9 (available in chapter9/exercise/ecommerce). Given this, now try to accomplish the following:

1. Update the ProductListComponent tests. Remove the isolated unit tests. Update the Angular tests to use the HttpTestingController to provide the list of stocks as well as handle quantity change.

2. Ensure that the list of stocks is reloaded when the quantity changes.

3. Add tests for the positive and negative cases of the CreateProductComponent. Check that the event is emitted when a product is successfully created as well.

Most of this can be accomplished using concepts covered in this chapter. You can check out the finished solution in chapter10/exercise/ecommerce.