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

By
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: https://github.com/suryakand/aem-angular2
  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

Installation

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 https://github.com/suryakand/aem-angular2/commit/316bdc3e2426f74c2d42a6d8339753f3cda4d485#diff-a068ef752f58b4eda47e5254ca70802d

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 https://github.com/suryakand/aem-angular2/blob/master/ui.apps/src/main/content/jcr_root/apps/ngaem/components/ui.tests/components/about.component.spec.ts

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:

Comments

Post a Comment

Popular posts from this blog

AEM as a Cloud Service (AEMaaCS) – Architecture Overview

By
Image
AEM as a Cloud Service (AEMaaCS) – Architecture Adobe Experience Manager (AEM) is one of the leading CMS from Adobe and is part of Adobe Experience Cloud (AEC). The Adobe Experience Manager (AEM) web content management offers a set of capabilities for creating, managing, delivering, and personalizing content across various digital marketing channels, including web, mobile, and email.  Before we dive into architecture of AEM as a Cloud Service (AEMaaCS) we need to understand why AEMaaCS is needed and how it is different as compared to classic AEM. To understand this, we’ll first look at: Evolution/history of AEM Challenges with traditional/classic AEM (the AEM that majority of us have used from last 10-12 years) Evolution/History of AEM The software was originally launched in early 2000 as Communiqué (CQ) by Day Software of Basel, Switzerland. After CQ 5.3 had been released, Day Software was acquired by Adobe Systems in 2010 then CQ became Adobe Experience Manager. From
Read more

AEM - Query list of components and templates

By
Some time while migration or for auditing purposes we need to know where a particular component/template or any other resource have been used. Have you ever wondered about how to fetch a list of all the paths where a particular component or template is being used? I this short article I am going to show a quick way to write a utility with which you can get list if paths (actual resource nodes) where a targeted resource is being used. Here is the code snipped: public void getResourceListHelper(Resource parentResource , String targetSearchPropertyKey ,  String targetSearchPropertyValue , List components ) {      Resource childResource ; for (Iterator resourceChildrenIter = parentResource .listChildren(); resourceChildrenIter .hasNext();  getResourceListHelper ( childResource, targetSearchPropertyKey, targetSearchPropertyValue, components)) { childResource = (Resource) resourceChildrenIter .next(); ValueMap childProperties = (ValueMap) childResource .adap
Read more

AEM 6.3 - Bundle Whitelisting - Deprecation of administrative authentication

By
Image
I stumbled on an issue when I was using neab with AEM 6.3. I created few neba ResourceModels and when I tried to access neba Model Registry, I got an error ( java.lang.IllegalStateException: org.apache.sling.api.resource.LoginException: Bundle org.eclipse.gemini.blueprint.extender is NOT whitelisted ): Image: neba Model Registry Menu Image: Error Screen NOTE: Neba team has already fixed it on their development branch and we don’t need to explicitly add whitelisting configuration for neba bundle. Here is the reason for error Originally the ResourceResolverFactory.getAdministrativeResourceResolver and SlingRepository.loginAdministrative methods have been defined to provide access to the resource tree and JCR Repository. These methods proved to be inappropriate because they allow for much too broad access. Consequently these methods are being deprecated and will be removed in future releases of the service implementations. The following methods are deprecat
Read more

Custom synchronisation or rollout action for blueprint ?

By
Image
Blueprint is an important feature for all those sites which needs to deals with multiple locale and region specific sites. Consider that we have 20 different regional sites and each regional site have 2 locales (English and regional language). Now let’s say you need to do a small update on a English locale page and that changes is required on all sites, there will be 20 pages that you’ll need to visit and make changes one by one (if you have not used blueprint and live copy). With blueprint  we can create a master copy (which is called as blueprint) and create many live copies (which are actual sites) and the benefit you get is that as soon as you do any change in blueprint that same change will be propagated to all live copies pages when changes are rolled out by authors…this is cool. With blueprint you’ll need to apply changes only to English locale page on blueprint and all English locale pages (live copies) will receive that change implicitly. So, how this whole thing works? W
Read more