Karma Config

The first file of interest is the configuration file for how Karma should find and execute files. The pregenerated karma.conf.js is in the main application folder, and looks like 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({
    basePath: '',
    frameworks: ['jasmine', '@angular/cli'],
    plugins: [
      require('karma-jasmine'),
      require('karma-chrome-launcher'),
      require('karma-jasmine-html-reporter'),
      require('karma-coverage-istanbul-reporter'),
      require('@angular/cli/plugins/karma')
    ],
    client:{
      clearContext: false // leave Jasmine Spec Runner output visible in browser
    },
    coverageIstanbulReporter: {
      reports: [ 'html', 'lcovonly' ],
      fixWebpackSourcePaths: true
    },
    angularCli: {
      environment: 'dev'
    },
    reporters: ['progress', 'kjhtml'],
    port: 9876,
    colors: true,
    logLevel: config.LOG_INFO,
    autoWatch: true,
    browsers: ['Chrome'],
    singleRun: false
  });
};

The Karma configuration is responsible for identifying the various plug-ins needed for Karma to run (which includes an Angular CLI–specific plug-in), the files it needs to watch or execute, and then some Karma-specific configuration including coverage reporting (coverageIstanbulReporter), which port it needs to run on (port), which browsers to run it on (browsers), whether it should rerun every time the file changes (autoWatch), and which level of logs it needs to capture.

test.ts

The test.ts file is the main entry point for our testing, and responsible for loading all our components, the related specifications, and the testing framework and utilities needed to run them:

// This file is required by karma.conf.js and loads recursively all the .spec
// and framework files

import 'zone.js/dist/zone-testing';
import { getTestBed } from '@angular/core/testing';
import {
  BrowserDynamicTestingModule,
  platformBrowserDynamicTesting
} from '@angular/platform-browser-dynamic/testing';

declare const require: any;

// First, initialize the Angular testing environment.
getTestBed().initTestEnvironment(
  BrowserDynamicTestingModule,
  platformBrowserDynamicTesting()
);
// Then we find all the tests.
const context = require.context('./', true, /\.spec\.ts$/);
// And load the modules.
context.keys().map(context);

The test.ts file is basically responsible for loading a series of files for the testing framework, and then initializing the Angular testing environment. Then, it looks for specifications (files ending with .spec.ts) recursively in all the folders from the current directory (which is the src folder). It then loads all the relevant modules for them and starts executing Karma.

This file is the reason why we don’t have to manually list all the specification files in karma.conf.js, as it recursively loads them.

An Isolated Unit Test

An isolated unit test in Angular terminology is a vanilla JavaScript unit test. This has nothing to do with Angular, but just instantiates classes and methods and executes them. This is sufficient for a large number of classes, as they will mostly be doing simple data manipulation and execution.

We will start with writing a very simple isolated unit test for the AppComponent using the example we were working on from Chapter 4. The base codebase to start with can be found in the GitHub repository in the chapter4/component-output folder.

The very first thing we will do is create (if it doesn’t already exist) a file right beside app.component.ts in the src/app folder called app.component.spec.ts. If it already exists and you haven’t deleted it yet, you can go ahead and clear the content, as we will write it from scratch so that we are aware of all the intricacies involved in the test.

The first two tests that we will write will focus on AppComponent as a class, and focus on its initialization and how a stock’s favorite state is toggled. In these tests, we will not focus on any Angular-specific functionality and see how to test AppComponent in isolation:

import { AppComponent } from './app.component';    
import { Stock } from 'app/model/stock';

describe('AppComponent', () => {      

  it('should have stock instantiated on ngInit', () => {   
    const appComponent = new AppComponent();      
    expect(appComponent.stock).toBeUndefined();    
    appComponent.ngOnInit();
    expect(appComponent.stock).toEqual(
      new Stock('Test Stock Company', 'TSC', 85, 80));   
  });

  it('should have toggle stock favorite', () => {
    const appComponent = new AppComponent();
    appComponent.ngOnInit();
    expect(appComponent.stock.favorite).toBeFalsy();
    appComponent.onToggleFavorite(new Stock('Test', 'TEST', 54, 55));
    expect(appComponent.stock.favorite).toBeTruthy();
    appComponent.onToggleFavorite(new Stock('Test', 'TEST', 54, 55));
    expect(appComponent.stock.favorite).toBeFalsy();
  });
});

Importing all relevant dependencies for our tests

Our main AppComponent test suite

The first test, each test being an it block

Instantiating the AppComponent

An expectation or assertion on what the behavior should be

Our final expectation on what the stock should be

Our isolated unit tests read just like plain old JavaScript, with Jasmine syntax thrown in. We first import our relevant class and interfaces to be able to use them in the specification. Then we define our first describe block, which is Jasmine’s way of encapsulating a set of tests as one suite. Describe blocks can be nested any number deep, which we will use in the feature to create separate describe blocks for Angular-aware tests versus isolated unit tests.

We then write our first test block, which uses Jasmine’s it to define a specification block. Within this, we define and instantiate our AppComponent instance, and then write an expectation that, by default, the stock instance of the AppComponent is undefined. We then call the ngOnInit method of the AppComponent manually, which creates a stock instance for us. We then write another expectation to make sure this value is created as we expect it to be.

Note that this behavior mirrors how the AppComponent behaves. When an instance of the AppComponent is created, we just have a definition for the stock object, but with no initial value. Thus, our initial expectation for the stock instance in the test is that it should be undefined. Then, we trigger the ngOnInit method, which ends up creating a stock instance with some values. We then assert in our test that the instance that gets created in the AppComponent actually has the values we want.

Similarly, we write the second test that evaluates the onToggleFavorite method on the AppComponent class. We pass a random value to it, as the value is not used in the class except to log it. We use a different expectation, toBeFalsy and toBeTruthy, instead of the toEquals we used in the previous test. These are all in-built matchers that Jasmine provides for us to use in our specifications. You can see the whole list of matchers that Jasmine provides out of the box in the official documentation.

Running the Tests

Running the actual tests, if you are using the Angular CLI as we are doing in this book, is actually very simple. Simply execute

ng test

from the command line in the root folder to execute the tests. This will:

1. Pick up the configuration from the karma.conf.js Karma configuration file

2. Load all the relevant tests and files as per the test.ts file

3. Capture the default browser (which is Chrome in our case)

4. Execute the tests and report the results in the terminal

5. Keep a watch on files to continue executing on change

You should see Karma capturing Chrome, and spawn up a browser that looks like Figure 5-1.

Figure 5-1. Angular tests running via Karma in Chrome

In the terminal, once you run the ng test command, you should see output similar to Figure 5-2.

Figure 5-2. Angular test output in the terminal

Once this completes, you should see (in both your Karma captured browser and the terminal) a result of having run two tests with both passing successfully.

Writing an Angular-Aware Unit Test

The next thing we want to learn is how to write a test that is Angular-aware and goes through the Angular lifecycle. In such a test, rather than just instantiating the component class, we want to instantiate a component just the way Angular does, including the HTML for the component.

We will write a test for the StockItemComponent, in which we will make sure that given the right stock input, the template gets rendered with the correct bindings. Furthermore, we want to make sure the input and output bindings are connected and triggered correctly.

Let’s create a stock-item.component.spec.ts file as a sibling to stock-item.component.ts. Again, if this file already exists, replace it with the following contents:

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

import { StockItemComponent } from './stock-item.component';
import { Stock } from '../../model/stock';
import { By } from '@angular/platform-browser';

describe('Stock Item Component', () => {

  let fixture, component;

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

  beforeEach(() => {            
    fixture = TestBed.createComponent(StockItemComponent);    
    component = fixture.componentInstance;      
    component.stock = new Stock('Testing Stock', 'TS', 100, 200);
    fixture.detectChanges();          
  });

  it('should create stock component and render stock data', () => {
    const nameEl = fixture.debugElement.query(By.css('.name'));     
    expect(nameEl.nativeElement.textContent).toEqual('Testing Stock (TS)');     
    const priceEl = fixture.debugElement.query(By.css('.price.negative'));
    expect(priceEl.nativeElement.textContent).toEqual('$ 100');
    const addToFavoriteBtnEl = fixture.debugElement.query(By.css('button'));
    expect(addToFavoriteBtnEl).toBeDefined();
  });

  it('should trigger event emitter on add to favorite', () => {
    let selectedStock: Stock;
    component.toggleFavorite.subscribe((stock: Stock) => selectedStock = stock);
    const addToFavoriteBtnEl = fixture.debugElement.query(By.css('button'));

    expect(selectedStock).toBeUndefined();
    addToFavoriteBtnEl.triggerEventHandler('click', null);
    expect(selectedStock).toEqual(component.stock);
  });
});

Importing Angular testing utilities

An async beforeEach, to ensure templates are loaded in the components

Using the Angular testing utilities to configure a module for testing

Compiling all the declared components for later use

A non-async beforeEach executed only after the previous one finishes

Creating an instance of the component fixture under test

Getting the underlying component instance from the test fixture

Manually triggering the Angular change detection to update templates

Getting a particular HTML element from the compiled element

Verifying that the element has the expected value

We have added a lot of code, and highlighted most of the important sections in the code as well. But let’s walk through it step by step so that we are aware of the intricacies of using the Angular testing utilities to write tests for components:

1. @angular/core/testing provides a set of functionality for testing in Angular. We use the TestBed, which is used to create modules and components while testing, and async, which is to allow the Jasmine framework to understand Angular’s async behavior (like loading templates for a component, which in our case is from an external template file). The async utility function ensures that we don’t start executing the test until these async tasks are finished. Notice how we call the async function with a function that does all the tasks which might be asynchronous, and then pass this result to the beforeEach.

2. We use the TestBed to configure a module for our test. Rather than using an existing module, we create a new module with just our component. This gives us absolute control and can also ensure that we don’t inadvertently depend on something else other than what we have defined. In this case, we declare the StockItemComponent, and then finally compile the component. This does the task of loading the component, loading all its related templates and styles, and then creating a compiled component for us to use later. This happens asynchronously in some cases, which is why we are wrapping it in an async block.

3. In the non-async beforeEach, we create a fixture, which is an instance of the component along with its template and everything related to it. Unlike the previous isolated unit test, where we unit tested just the component class, the fixture is the combination of the template, the component class instance, and Angular’s magic to combine the two.

4. From the fixture instance, we can get a handle to the underlying component class instance by using the componentInstance variable on it. We can then manipulate the inputs and outputs directly from the component instance.

5. In this test, we are not working with a higher-level component, so we cannot directly test the Input and Output bindings. But we can set these values by accessing them directly from the component instance.

6. Finally, in the beforeEach, we trigger fixture.detectChanges(). This is a signal to Angular to trigger its change detection flow, which will look at the values in the component and update the bindings in the corresponding HTML. It is also the trigger to execute the ngOnInit for the component the very first time. Without this, the HTML for the component will not have any values. We trigger this after setting the stock value so that these values will be propagated to the HTML.

7. In the actual tests, we can get access to individual elements from the generated component by using the fixture.debugElement and running CSS queries against it. This allows us to check whether the template has the correct bindings and values. Thus, we can avoid writing an end-to-end test for a lot of these basic checks and simply write Angular tests for them.

8. In the second test, we can actually see that when we trigger a click event on the button element in the template, the corresponding function in the StockItemComponent class is triggered, and an event is emitted with the current stock value.

Similarly, we can write a test for most components and test the interaction with the templates and get a good sense for most of the basic functionality and whether it is working as intended.

Testing Component Interactions

The final thing that we’ll need to check is whether the AppComponent and the Stock​ItemComponent interact with each other correctly, and whether the stock value is passed from the AppComponent to the StockItemComponent as input correctly. We can also test these functionalities and more using the Angular testing utilities. Let’s extend our tests for the AppComponent by adding another sub-suite as follows in the app.component.spec.ts file:

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

import { AppComponent } from './app.component';
import { StockItemComponent } from 'app/stock/stock-item/stock-item.component';
import { Stock } from 'app/model/stock';
import { By } from '@angular/platform-browser';

describe('AppComponent', () => {

  describe('Simple, No Angular Unit Test', () => {
    /** Move all the previous test code into a
        child describe block
    */
  });

  describe('Angular-Aware test', () => {

    let fixture, component;

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

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

    it('should load stock with default values', () => {
      const titleEl = fixture.debugElement.query(By.css('h1'));
      // Trim to avoid HTML whitespaces
      expect(titleEl.nativeElement.textContent.trim())
          .toEqual('Stock Market App');

      // Check for default stock values in template
      const nameEl = fixture.debugElement.query(By.css('.name'));
      expect(nameEl.nativeElement.textContent)
          .toEqual('Test Stock Company (TSC)');
      const priceEl = fixture.debugElement.query(By.css('.price.positive'));
      expect(priceEl.nativeElement.textContent).toEqual('$ 85');
      const addToFavoriteBtnEl = fixture.debugElement.query(By.css('button'));
      expect(addToFavoriteBtnEl).toBeDefined();
    });

 });

});

Most of this test will look very similar to the previous test we wrote for the StockItemComponent, but here are a few notable differences:

• When we configure our testing module, this time we have to mention both the AppComponent, which is the component under test, as well as the StockItemComponent. This is because the AppComponent uses the StockItemComponent internally, and without declaring it, Angular would complain about an unknown element.

• No major changes to either of the beforeEach other than this. One thing to note (and it’s worth playing around with and trying it out yourself) is that without the fixture.detectChanges() in the second beforeEach, none of the bindings would happen. You can test this by commenting it out and making sure the test fails.

• Our test follows a similar pattern like before (in fact, it is pretty much a copy/paste of the previous test for StockItemComponent). The one thing to note is we are trimming the actual text contents retrieved from the DOM to account for extra whitespaces in the HTML from how we have done our binding. This can be useful sometimes when the HTML is not an exact replica of your bound value.

Let’s quickly add another test that ensures that the end-to-end flow is both ways. We will add a test that makes sure that clicking Add to Favorite updates both the model value as well as hiding the button in the template. The following code is just the test, ignoring the imports and everything else. This is a part of app.component.spec.ts like the previous specification:

it('should toggle stock favorite correctly', () => {
  expect(component.stock.favorite).toBeFalsy();
  let addToFavoriteBtnEl = fixture.debugElement.query(By.css('button'));
  expect(addToFavoriteBtnEl).toBeDefined();
  addToFavoriteBtnEl.triggerEventHandler('click', null);

  fixture.detectChanges();
  expect(component.stock.favorite).toBeTruthy();
  addToFavoriteBtnEl = fixture.debugElement.query(By.css('button'));
  expect(addToFavoriteBtnEl).toBeNull();
});

First, we check the base default value to ensure that the stock is not favorited by default and that the Add to Favorite button is present. Post that, we trigger the click event on the button.

At this point, Angular is supposed to kick in, emit an event from the StockItemComponent to the AppComponent, change the model value, trigger the change detection flow, and update the UI. But in our test, we need to tell Angular to trigger the change detection flow, and hence after we trigger the event, we manually call fixture.detectChanges().

After this, we can write our assertions to ensure that the behavior matches our expectations.