Why Test my Code

Before we begin let’s highlight the main reasons for writing tests.

Unit Tests help you understand the design of the code you are working on and to think about all the possibilities.

Unit Tests can help document and define what something is supposed to do.

If you change something in the code and the tests still pass you can be sure you have not broken anything.

Now that you are convinced that you need to test your code we can start 😀.

Presentational (aka Dumb) components are usually only responsible for displaying data based on their Inputs and communicating with their parent through Outputs . Therefore they are much easier ( and fun ) to test.

Let’s start by creating a dumb component for the alert style of bootstrap css.

There’s nothing to explain here. The code is very simple. Let’s start with the tests.

TestBed is an Angular utility that helps you create a module for tests. The configureTestingModule method takes an @NgModule -like metadata object.

In our case, we only need two things, the component that we want to test ( AlertComponent ) and a host component.

We need to call configureTestingModule within a beforeEach so that TestBed can reset itself to a base state before each test runs.

Now let’s think about the process. Most of your it blocks will do something like this:

Change the host template (i.e., inputs) Run change detection. Make assertions as to what should have happened.

It would be 😎 if we can change the host template in every it block. In fact, we can, let’s see how.

After configuring TestBed , you can create an instance of the component that you want to test by calling the createComponent method with the component blueprint.

The createComponent method returns a ComponentFixture , a handle on the test environment surrounding the created component. The fixture provides access to the component instance itself and to the DebugElement , which is a handle on the component's DOM element.

TestBed also provides several methods to allow us to override dependencies that are being used in a test module, one of them is the overrideComponent .

Let the fun begin.

Just look at it, who needs documentation? Sweet! 😋

Now let’s see how to test the close output.

As you may know Outputs in Angular are Subjects ( i.e., observables ) so we can subscribe to them to get the value. In our case, we need to subscribe to the close emitter that we can get from the component instance, save the value in a local variable, trigger the event and make our assertion.

Note: As opposed to promises, observables are not always called asynchronously. By default Angular emitters are synchronous, and that’s why we don’t need to use the fakeAsync utility in our case.

Summary

In this article, we saw one of the methods of writing tests for dumb components in Angular. Now that you know the concept you can do all sorts of abstractions to reduce the repeating code. Good Luck!

Follow me on Medium or Twitter to read more about Angular, Vue and JS!