Part 4: AEM with Angular 2 - Unit Testing Angular Components & Services

This article is continuation of a multi-part series on AEM + Angular 2 integration. You can read previous 3 articles from this series here:
In previous three parts, we have learned:
  1. Angular 2 & Challenges of using AEM with Angular 2
  2. Project Structure of AEM + Angular 2 project and custom build script
  3. Developing AEM components using Angular 2
In this part, we’ll learn about Unit testing Angular code base and collecting code coverage matrix.

Unit testing is very important from code quality perspective and it becomes even more important when project is large and multiple teams are working on same project. In large projects, dividing large systems in to small and loosely coupled modules is a best practice but then, it becomes very critical to test each of these modules independently without explicit depending on each other. This is very critical from unit testing perspective.

In AEM, we have reusable components that can be used to create variety of content and it becomes very important to test each component. Typically, an AEM component have:
  1. User Interface (JSP, Sightly etc.) and JavaScript (Angular.js, React.js etc.)
  2. Some backing object/Sling Model 
  3. And/or WCM Use class (Java or JavaScript based)
In a well-designed and architected application, each of these 3 pieces should be independently unit testable. In this article, we’ll be focusing on testing User Interface i.e. #1

Unit testing UI is simple as compared to developing AEM components using Angular 2. It is simple because, for testing we are not doing anything different just because we are using AEM, testing will be done in usual way as we would do when we are not using AEM.

NOTE: Since we have our custom build script for building project, we won’t be using Angular CLI and standard project structure for testing.

I am going to use same project from my github repository and will add everything that we need for unit testing UI (Angular code).

Before we proceed, let’s refresh few things:
  1. Code for this project is here:
  2. In previous articles in this series we learned that we have two separate builds:
  • gulp build” – builds project so that everything can be testing as if it is regular angular application. This build generates artifacts on build folder and you can run following command to run the application “npm run start”
  • gulp build:aem” – build projects in such a ways that everything is packaged as crx package that can be deployed into AEM


If you have followed first 3 articles in this series, then you should be good with installation. Please refer those articles for installation. Here are links to previous articles:

Testing Frameworks

For UI unit testing we’ll be using:
  1. Jasmine - Jasmine is a JavaScript testing framework that supports a software development practice called Behavior Driven Development, or BDD for short
  2. Karma - Manually running Jasmine tests by refreshing a browser tab repeatedly in different browsers every-time we edit some code can become tiresome. Karma is a tool which lets us spawn browsers and run jasmine tests inside of them all from the command line. The results of the tests are also displayed on the command line. Karma can also watch your development files for changes and re-run the tests automatically. Karma lets us run jasmine tests as part of a development tool chain which requires tests to be runnable and results inspectable via the command line.
  3. Istanbul - a JS code coverage tool written in JS. 

Project Configuration

To write and execute we need to add/update some configuration files. In this section we’ll see go over these changes.

  • include UI unit testing and test runner dependencies in package.json file and “run npm” install again

  • Add a task to run unit test

2. Add karma runner configuration (karma.conf.js) – Complete configuration file is here

This file, defines where to look for JS files that needs to be considered for testing, which testing framework to used for testing, what reporters (code coverage framework) to use and what port Karma should run etc.

Write Unit Test Cases

I have added a new folder called “ui.tests“ where we’ll write all test cases for our Angular code. New folder structure looks like this

From Angular perspective, there are 2 main entities for which we need to write test cases:
  1. Angular Components
  2. Angular Services
Let’s write a test case for Angular component. For this article we’ll write a very basic test case for “about.component”. You can refer full example of “about.component” test case here

Here are basic steps involved in writing a test case:
  1. Import mock test dependencies, components and services needed for testing
  2. Initialize mock Angular environment/TestBed (as if we do in with real application in browser) by loading/initializing angular components and services. This mock angular environment initialized for testing is referred as TestBed. To simplify this I have created a utility class “UtilTestBed”. You can use this class initialize mock TestBed in one line, see line# 19 below
  3. Write logic/asset statements to test components. In this step, we create an instance of component that we want to test and verify that it has been rendered properly. Verification can be done in various ways e.g. verify that expected HTML element is rendered (line# 30 below), text/value of rendered element (line# 37 below)

Same method can be followed for writing test case for angular services too.

Once you have writing test cases, you can execute them using following command:

npm run test

You should see following output after execution is completed:

Verifying Code Coverage Report

Once all test cases are finished, navigate to the “/aem-angular2/ui.apps/target/reports/coverage/report-html” folder and open index.html to see code coverage report. The report would look like this:

I hope this article will help you to implement unit tests for you front end code and will help you to maintain your code quality.

Thanks for reading!!!

Reference to other articles in this series:


Popular posts from this blog

Sling Authentication

CQ Development - OSGi bundles and Components

Create an AEM (CQ) project using Maven

Multiple log files using log4j appender