Angular Unit Testing : Jasmine & Karma

Angular Unit testing is super-exciting, but at the same time, it’s the vastest topic too, so let’s dive deep into it to simplify it! 

Let’s Start With What Is Angular Unit Testing?

It is a software development process in which the smallest testable parts of an application are known as units which are individually and independently looked over for proper operation. This unit testing methodology is done during the development process by the software developers.

Here is a detailed video about Angular  Unit Testing: Jasmine & Karma

What Is The Need For Angular Unit testing?

As we all know, as a developer, we tend to add new pieces of code daily. So, our new code and a new piece of code we are adding daily. That should not change the expected output for the known set of input.

Let’s quickly jump to an example to get a brief idea:

So, here we have created a demo application for testing. It is a Utility application i.e., a to-do application.

In the above image, we can see that this application is a Utility Application in which we display the list of tasks with priorities and perform an add, update and delete (basically CRUD) operation. As we know, an angular project comprises templates, components, services and modules. They all run inside what is known as the angular environment. 

And we get an in-built file for testing in every component we create with the help of an angular CLI, i.e., spec.ts file. By that logic, unlike other frameworks, we need not create a different file for testing. Let’s see an example:

We are using Jasmine and Karma in this project for unit testing. Karma acts as a driver i.e., “Test Runner” of the project, and Jasmine is a Framework for writing angular tests.

import { TestBed } from '@angular/core/testing';
import { RouterTestingModule } from '@angular/router/testing';
import { AppComponent } from './app.component';

describe('AppComponent', () => {
  // Executes before each test case
  beforeEach(async () => {
    await TestBed.configureTestingModule({
      imports: [
        RouterTestingModule
      ],
      declarations: [
        AppComponent
      ],
      // Converts angular templates into standard HTML templates
       // Compiling angular language into basic HTML that can be understood by a 
headless browser (browser without UI)
    }).compileComponents();
  });

  it('should create the app', () => {
    const fixture = TestBed.createComponent(AppComponent);
    // Object of class


 const app = fixture.componentInstance;
    expect(app).toBeTruthy();
  });

  it(`should have as title 'utility-app'`, () => {
    const fixture = TestBed.createComponent(AppComponent);
    const app = fixture.componentInstance;
    expect(app.title).toEqual('utility-app');
  });

  it('should render title', () => {
    const fixture = TestBed.createComponent(AppComponent);
    // Detect changes in UI
    fixture.detectChanges();
    // HTML DOM element rendered by the component
    const compiled = fixture.nativeElement;
    expect(compiled.querySelectorAll('app-header-bar').length===1).toBe(true);
  });
});

As in the above piece of code, we can see the app.component.spec.ts file. So this file, by default, comes with certain pieces of code and we can also add our own test cases. 

Basically, the anatomy of Jasmine  is made up of at least two elements:

A describe(), which is a suite of tests and it(), which is a test itself. We normally use describe() to indicate the function we are focusing on. Then, within that, we create multiple tests. Each test puts the target() under a different condition in order to ensure it behaves as expected.

In the code, we are using 

=> describe() i.e. indicating that we are focusing on AppComponent. 

After that we can see the 

=> beforeEach(), so every beforeEach() 

Block executes before each test case. We use an async beforeEach. The purpose of async is to let all the possible async code finish before continuing. After that we are using the TestBed.configureTestingModule() to create a module environment for testing the component. It is similar to the NgModule, the difference is that, in this case we are creating a module for testing.

We have imported the “RouterTestingModule”

=> The RouterTestingModule easily solves the activatedRoute and location dependencies in our test code. The RouterTestingModule also handles other situations where routing is involved.

Then we have .compileComponents()

=> It compiles the Angular language into standard HTML that can be understood by a headless browser(browser without UI). As our browser doesn’t understand Angular, React, it only understands the standard HTML 

That’s why we need .compileComponents().

Finally, we have the spec; under the it() block, we write our spec, so our first spec is that “should create the app”, where we confirm that the component has to be initialized. If this test passes, the component should run properly within an Angular environment.

Our second spec is that “should have as title ‘utility-app’”, in this case, we are creating an instance of the component under test and expecting the title to be equal to ‘utility-app’.

Our third spec is that “should render title”, in this case, we are creating an instance of a component under test then we are using  detectChanges(), which we are using to detect changes in the UI. And the nativeElement which helps HTML DOM(Document object model) element rendered by the component. Finally, it is expected that the length of the title should be ==1. So, 

Here we are done with the test cases we have written for our appComponent.

Similarly, we have written test cases for all other files, the anatomy is the same but with different specs.

After writing all the test cases, to check how many of our test cases have been passed and how much has been failed, we need to run a command i.e. “ng test”. After hitting this command, we will get a window opened in our 

Browser like this:

Here, we can see that we have written 12 specs, and all the test cases have been passed.

Similarly, if any test cases fail, we can see it in the

Window only like this:

This is how we test our specs. 

After all these steps, one of our biggest questions is “have we tested enough code?” On that note, we have tools that can generate “Code Coverage” to determine how much of our code is tested.

To generate the report, we need to run the following command:

ng test --watch=false --code-coverage

After that, a coverage folder will be created at the root of the angular project. Navigate inside the folder, and we will find index.html. Open it in the browser, and we can see something like this: 

Here, some classes have been tested fully while others have not completely. Due to time and availability of resources, it often isn’t always possible to implement 100% test coverage.

Basically, code coverage is a measurement of the amount of code i.e. run by unit tests – either lines, branches or methods. And it provides us the “Overall Test Coverage Statistics”.