Understanding Test Configurations in Angular

Learn how to configure different types of tests with Angular’s latest features.

Bhargav Bachina
Bits and Pieces

--

Photo by Eric Prouzet on Unsplash

Tests are crucial for any product or software before releasing that into production. We have different types of tests such as unit tests, e2e tests, etc. and it’s essential to have a proper configuration for all the types of testing. In this article, we go through types of tests and how to configure using angular.json in the Angular project.

  • Example Project
  • Types of Testing/Test Suites
  • How to configure and Implement
  • Implementation
  • Some Other Features
  • Summary
  • Conclusion

Tip: Use Bit to collaborate on Angular components for faster development and more consistent UI/UX

Use Bit to share, install and collaborate on individual Angular components. Stop wasting time configuring packages, managing multiple repositories or maintaining cumbersome monorepos.

Example: UI components shared in Bit’s cloud

Example Project

Here is an example project for this article. Let’s not do anything fancy since we are focussing on setting up configurations for end-2-end tests.

// clone the project
git clone https://github.com/bbachi/angular-configuration-example.git
// install dependencies and start the project
npm install
npm start

Here is the project which has a header, footer, and dashboard which contains a table of test types, and when you click on each one, the description appears on the right side of the screen.

Example Project

Types of Testing/Test Suites

When it comes to testing any application, there are two methodologies: BDD (Behavioral-driven development)and TDD (Test-driven development). We are not going to talk about these since our primary focus is on the configuration in the Angular project. We have different types of tests irrespective of methodologies. These are named as test suites as well. Here are some of those.

  • Unit tests
  • Integration tests
  • Regression tests
  • Performance tests
  • Load tests
  • End-to-End (e2e) tests
  • UAT (user acceptance tests)
  • Smoke Tests

Unit tests

These tests refer to testing isolated components which means testing without any dependencies. If your component or testing unit depends on any service or any other configuration, we should mock those. We should only focus on the unit that we are testing. Unit tests should be fast since we mock all the dependencies and avoid all the network calls or any other i/o reads or writes to make the test faster.

Integration tests

These tests refer to testing partial or entire components together to assure correct functionality when they are working together. For example, if we have frontend and backend for an app, we set up some test data for the backend and test the frontend to ensure that the correct data is displayed. We test with some test data to make sure all the components are working correctly when they are integrated.

Regression tests

These tests refer to the testing issues raised in the application over time. We usually get issues from the prod applications. Whenever we get an issue, a unit test is created along with fixing that issue. We run these unit tests as regression tests before every prod release to avoid the same issue happen over and over.

Performance tests

These tests refer to how fast one transaction is. It focusses on the speed of one transaction.

Load tests

These tests focus on the speed of the application with concurrent users. The difference between performance and load tests is that the former focus on the speed of single transactions and the later focusses on speed with simultaneous users and multiple requests at the same time.

End-to-End (e2e) tests

In e2e tests, we emulate the real production environment and test the real scenarios. It’s almost similar to full integration tests except for the test data. It is tested with the real production environment.

UAT (user acceptance tests)

We usually get all the requirements from the end-user before building any application. These tests ensure that the application meets all the requirements from the end-user.

Smoke Tests

Every application has some essential functions or components. These tests ensure that all the vital functions or parts of the application are working correctly before every production release.

How to configure and Implement

Since we are focusing on the configuration, we are not going to implement all the testing types with this project. We are going to implement these types with minimal test Tests, Regression Tests, Smoke Tests, UAT Tests and e2e Tests.

Unit Tests

In Angular, unit tests are written in the Jasmine framework, executed by test runner karma and runs in the browser.

Unit Tests

Here is the part of angular.json where unit tests are configured. When you run npm test from the package.json, Angular takes the configuration from the angular.json under the test object. The first file it invokes is the test.ts and takes the karma configuration from the karma.conf.js

unit tests configuration in angular.json

These are the main test.ts and karma.conf.js files. We can put which browser we should use, reporter configuration, which testing framework should be used, etc.

configuration files

I have already written some unit tests for the components App, header, and footer components, and you can download the whole project from here. Let’s run npm test and below is the output in the console and the browser.

Karma running unit tests
console output

All Other Tests

In Angular, all other tests (Regression Tests, Smoke Tests, UAT Tests and e2e Tests) are written in jasmine framework, executed by protractor framework and runs in the browser as well as headless. You can use other options as well, such as cypress, jest, etc.

Protractor Tests

Here is the part of angular.json where e2e tests are configured. When you run npm run e2e from the package.json, Angular takes the configuration from the angular.json under the e2e object. If you look at the options, it has two properties protractorConfig, which is the configuration file and devServerTarget, which is the target that we run tests against.

e2e configuration

We can have multiple configuration protractor files that execute different test suites. Below is an example of protractor.conf.js which executes all the specs which end e2e-spec.ts. It has a lot of other features like reporting, baseUrl, browser, etc.

protractor.conf.js

Let’s add configurations to the e2e object to run other test types smoke, uat, e2e, and regression.

other configurations

Once you add the configurations object like above, you can run any test with this flag ng e2e -c <configuration name>. For instance, you can run the smoke test with this ng e2e -c smoke.

console output

Implementation

Let’s implement some simple scenarios as examples. Once the configuration is done, We can execute all these tests with these commands. We can configure these in package.json as well.

// unit tests
ng test
// e2e tests
ng e2e -c e2e
// smoke tests
ng e2e -c smoke
// regression tests
ng e2e -c regression
// uat tests
ng e2e -c uat
package.json scripts

UAT Tests

We have only two test cases for UAT tests: one is we should have the title in the header and should display the current year in the footer. Here are the file and the console output. You can run the tests with npm run e2e:uat or ng e2e -c uat.

app-title-uat.e2e-spec.ts

Regression Tests

For the Regression tests, there is a bug in the production in the previous releases that the dashboard must-have titles Types of Tests and Test Description

Dashboard Titles

Here are the file and console output for the regression tests.

dashboard-title-regression.e2e-spec.ts
console output

Smoke Tests

The essential component of this application is that when we click on the test type, the test description should be displayed on the right side. Let’s test that scenario as the smoke test. Here are the spec file and console output. We can run the smoke tests with this command ng e2e -c smoke.

dashboard-smoke.e2e-spec.ts
console output

Some Other Features

Let’s discuss some other common features in e2e testing.

Running Tests in Headless Browser

Sometimes we have to run tests in a headless browser. A headless browser is a browser without the graphical user interface. We can configure that in the protractor.conf.js under the capabilities section. When you can run tests with the headless argument like below, you won’t see browser running while running the tests.

protractor.conf.js

How to configure the URL that you want to run tests against

We can set the URL that you want to run tests with the baseUrl option. We can do this with protractor.conf.js. For instance, if we have multiple environments for our application like dev, test and, prod, we can configure those like below in the protractor.conf.js file.

// protractor.conf.jsbaseUrl: 'http://dev.example.com/',

How to generate HTML report for your e2e tests

We can create reports for the tests with the help of these libs.

const { SpecReporter } = require('jasmine-spec-reporter');
const jasmineReporters = require('jasmine-reporters');
const PrettyReporter = require('protractor-pretty-html-reporter').Reporter;

Here is the configuration to generate the report. You can clone the complete project from here and run the tests. You can see the reports produced under the target folder.

protractor.conf.js

If you want to check how to run e2e tests in Docker. Please check out this article.

If you want to know more about Angular unit testing. Here is the article.

Summary

  • Testing the application is very important and gives us a lot of confidence before any production release
  • We have a lot of testing types such as Smoke tests, integration tests, e2e tests, etc.
  • We can configure all these tests with the help of angular.json so that we can avoid manual work.
  • Unit tests are written in the Jasmine framework, executed by test runner karma and runs in the browser.
  • All the e2e tests written in jasmine framework, executed by protractor and runs in the browser
  • We can run tests with a headless browser which we can run with a command-line interface.
  • We can configure the angular.json so that we can run multiple test types without manual intervention.

--

--