Introducing Unit Tests in Angular

We familiarized ourselves with unit testing and its general concepts, such as test suites, test specs, and assertions. It is now time to venture into unit testing with Angular. Before we start writing tests for Angular, though, let’s have a look at the tooling that the Angular framework and Angular CLI provide us with to make unit testing a pleasant experience:

• Jasmine: We have already learned that this is the testing framework.

• Karma: The test runner for running our unit tests.

• Angular testing utilities: A set of helper methods that assist us in setting up our unit tests and writing our assertions in the context of the Angular framework.

When we use the Angular CLI, we do not have to do anything to configure Jasmine and Karma in an Angular application. Unit testing works out of the box as soon as we create a new Angular CLI project. Most of the time, we will interact with the Angular testing utilities.

Concepts that help in Angular testing

Angular testing utilities help us create a testing environment that makes writing tests for our Angular artifacts easy. It consists of the TestBed class and various helper methods that can be found under the @angular/core/testing namespace. As this chapter progresses, we will learn what these are and how they can help us test various artifacts. For now, let’s have a look at the most commonly used concepts so that we are familiar with them when we look at them in more detail later on:

• TestBed: A class that is the most crucial concept. It essentially creates a testing module that behaves like an ordinary Angular module. When we test an Angular artifact, we detach it from the Angular module it resides in and attach it to this testing module. The TestBed class contains the configureTestingModule method we use to set up the test module as needed.

• ComponentFixture: A wrapper class around an Angular component instance. It allows us to interact with the component and its corresponding HTML element.

• DebugElement: A wrapper around the DOM element of the component. It is an abstraction that operates cross-platform so that our tests are platform-independent.

Now that we know our testing environment and the frameworks and libraries used, we can start writing our first unit tests in Angular. We will embark on this great journey from the most fundamental building block in Angular, the component.

Testing components

We may have noticed that every time we used the Angular CLI to scaffold a new Angular application or generate an Angular artifact, it created some test files for us.

Test files in the Angular CLI contain the word spec in their filename. The filename of a test is the same as the Angular artifact that it is testing, followed by the suffix .spec.ts. For example, the test file for the main component of an Angular application, app.component.ts, would be app.component.spec.ts and would reside in the same path as the component file.

Note: We should think about an Angular artifact and its corresponding test as one thing. When we change the logic of the artifact, we may need to modify the unit test as well. Placing unit test files with their Angular artifacts makes it easier for us to remember and edit them. It also helps us when we need to do some refactoring to our code, such as moving artifacts (not forgetting to move the unit test).

When we scaffold a new Angular application, the Angular CLI automatically creates a test for the main component, AppComponent. At the beginning of the file, there is a beforeEach statement that is used for setup purposes: