The complete guide to designing, developing, testing, and deploying enterprise applications with Angular

Angular Applications Architecture

Requirements and FAQs

Code style guide

Introduction

Start from the domain

Software architecture for Front-end

Domain, design, develop

Workspaces scenarios

Applications and Libraries

Mono repository multi project

Domain boundary with plain TypeScript

Application details with Angular

Presentational details with Angular

Domain boundary and application details

Testing big Angular solutions with ease

Narrow tests for business logic

Visual tests for the presentation layer

Wide tests for the user experience

Testing since the beginning

Configuration environment and tokens

Instrumentation measuring and logging

Security authentication and authorization

Core generic infrastructure

A library for your shared UI vocabulary

A set of basic atomic elements

Some generic composed blocks

User interface, a design system foundation

Reactive stores with Signals

API access as a commodity

Interceptors for the dirty job

Data stores, reactive access, and persistence

Features come in routes to pages

Anatomy of a Page control flow and services

Different levels of state management

Routes and pages

In this course we teach you how to design, develop, ane deploy enterprise level Angular Applications the right way. Despite the fact that Angular is an opinionated framework, specially suited to build large solutions, it requires a deep knowledge to take decisions at every step.

In almost 30 lessons we cover how to choose and use the correct tools, how to structure an application that scales and how to code some intricate solutions to common problems. It's a long course/book and comes with a complete working codebase fully tested.

It is taught by Alberto Basalo who has been working, advising, and training multinational corporations, banks, and public administrations in Angular for years.

The complete guide to design, develop, test, and deploy enterprise applications with Angular

How to design, develop and deploy big enterprise applications with Angular.

Best practices to organize your code in small reusable libraries.

Application of reactive flow patterns for better user and developer speed.

Leverage the latest Angular version features like stand-alone components.

Common functionality for any application ready to use.

Testing helps you catch bugs early, ensure quality, and confidently deploy solutions. The good news is that testing Angular could be really easy. With a solid understanding of testing principles, you can become proficient in testing your code quickly. 

This chapter will teach you the basics of testing, the different types of testing, and the solutions that Angular provides to make testing easy.

As we know, testing code is an essential part of the software development process. Being part of that process does not make it cost less. I tend to see it as a money investment; you should calculate the cost/benefit. 

Having a solid understanding of testing principles will help you reduce the cost and time required to maintain the code and have a good return on the investment. Take five minutes to review or learn the basis of testing.

If you ask me why test your code, I would say to catch errors early. That's the main reason why you should test your code. Testing helps you catch errors early in the development process. The earlier you catch errors, the easier it is to fix them.

Testing should be an ongoing process throughout the software development lifecycle. Testing should begin as soon as possible, ideally during the development phase. If the team is proficient in testing, they can follow the 

 methodology and write the test before the code.

However, some tests can be time-consuming or require a wide view of the application and are usually performed as part of the code integration process.

When writing tests, you look for two emotions: joy or pain. Let me explain. Some tests are meant to give you the confidence that your code works as expected when it passes. On the other hand, some tests can pinpoint the exact line of code that is causing the problem when failing.

Each type of test has its pros and cons. Let's explore the different types of tests and the emotions they bring.

Suppose you are looking for the joy of having a test suite that gives you confidence that your code works as expected; this is your scenario. Testing functionality as a user or high-level programmer is usually called 

The more code you run during a test, the calmer you'll be if it passes. So, don't hold back when testing use cases and workflows, and create tests that exercise the most code you can.

The downside of this type of test is that they do not give you any clue about what happens when they fail. You have to debug the code to find the problem. Or have more use cases that may or may not fall also. Anyway, you have work to do to find the offending code.

Another drawback is that they are costly and slow to run. So, is not easy or practical to run them after every code change. Instead, most programmers run them before deployment or as part of your CI/CD pipeline. 

, are being improved, so you can run them more often than you may expected. Those are my chosen tools for writing end-to-end tests in the typical scenario of testing a web application. 

If you want to ensure the code doesn´t break and find any bugs as soon as possible, you must test less code. The less code you exercise, the easier it is to find a bug when it happens. 

And the minimum quantity of something is one. Testing a single function or a single module is usually called a 

. If the test fails, the problem must be in 

 under test. So you can quickly find the problem and fix it. Yes, looking for pain can make you happy.

The downside of this type of test is that you have to write many tests to cover all the code paths. To achieve unit independence, you have to mock all the dependencies of the function or the module under test, so it can be isolated from any other point of failure.

The good news is that this kind of test is usually fast to run, so you can run it after every change to get quick feedback.

In Angular, you can use a tool like the official default, 

 to run them in watch mode at every single file save.

As you can see, testing is a broad topic, and some guidance is welcomed to approach. You should know what to test, how to test, and when to test. Some tests are made to ensure functionality, while others are meant to catch errors. The technology needed to test the business logic differs from testing the presentation layer. Some tests require time and resources to run. 

We can choose from various test types like unit, integration, and end-to-end tests. The Angular ecosystem provides us with specific tolls for each technology, like Jest or Cypress. Tests can be run while coding, before pushing changes, or before deploying the application. You should have a strategy in mind to test your code.

The following table can guide you based on the code you want to probe.

I have chosen the following options for the demonstration code accompanying this book.

---
title: Testing big Angular solutions with ease
isPublicLesson: false
useMdx: true
---

# Testing big Angular solutions with ease

Testing helps you catch bugs early, ensure quality, and confidently deploy solutions. The good news is that testing Angular could be really easy. With a solid understanding of testing principles, you can become proficient in testing your code quickly. 

This chapter will teach you the basics of testing, the different types of testing, and the solutions that Angular provides to make testing easy.

## Why, when, and how to test

As we know, testing code is an essential part of the software development process. Being part of that process does not make it cost less. I tend to see it as a money investment; you should calculate the cost/benefit. 

Having a solid understanding of testing principles will help you reduce the cost and time required to maintain the code and have a good return on the investment. Take five minutes to review or learn the basis of testing.

### Tests help you catch errors early.

If you ask me why test your code, I would say to catch errors early. That's the main reason why you should test your code. Testing helps you catch errors early in the development process. The earlier you catch errors, the easier it is to fix them.

### Test as soon as you can.

Testing should be an ongoing process throughout the software development lifecycle. Testing should begin as soon as possible, ideally during the development phase. If the team is proficient in testing, they can follow the _Test Driven Development (TDD)_ methodology and write the test before the code.

However, some tests can be time-consuming or require a wide view of the application and are usually performed as part of the code integration process.

## What are you looking for?

When writing tests, you look for two emotions: joy or pain. Let me explain. Some tests are meant to give you the confidence that your code works as expected when it passes. On the other hand, some tests can pinpoint the exact line of code that is causing the problem when failing.

Each type of test has its pros and cons. Let's explore the different types of tests and the emotions they bring.

### Wide outlook.

Suppose you are looking for the joy of having a test suite that gives you confidence that your code works as expected; this is your scenario. Testing functionality as a user or high-level programmer is usually called **integration tests** or **end-to-end tests**.

The more code you run during a test, the calmer you'll be if it passes. So, don't hold back when testing use cases and workflows, and create tests that exercise the most code you can.

The downside of this type of test is that they do not give you any clue about what happens when they fail. You have to debug the code to find the problem. Or have more use cases that may or may not fall also. Anyway, you have work to do to find the offending code.

Another drawback is that they are costly and slow to run. So, is not easy or practical to run them after every code change. Instead, most programmers run them before deployment or as part of your CI/CD pipeline. 

Some tools, like [Cypress](https://www.cypress.io/) or [Playwright](https://playwright.dev/), are being improved, so you can run them more often than you may expected. Those are my chosen tools for writing end-to-end tests in the typical scenario of testing a web application. 

### Narrow focus.

If you want to ensure the code doesn´t break and find any bugs as soon as possible, you must test less code. The less code you exercise, the easier it is to find a bug when it happens. 

And the minimum quantity of something is one. Testing a single function or a single module is usually called a **unit test**. If the test fails, the problem must be in _the function_ or _the module_ under test. So you can quickly find the problem and fix it. Yes, looking for pain can make you happy.

The downside of this type of test is that you have to write many tests to cover all the code paths. To achieve unit independence, you have to mock all the dependencies of the function or the module under test, so it can be isolated from any other point of failure.

The good news is that this kind of test is usually fast to run, so you can run it after every change to get quick feedback.

In Angular, you can use a tool like the official default, [karma/jasmine](http://karma-runner.github.io/), or the fastest [Jest](https://jestjs.io/) to run them in watch mode at every single file save.

### Test with a strategy in mind.

As you can see, testing is a broad topic, and some guidance is welcomed to approach. You should know what to test, how to test, and when to test. Some tests are made to ensure functionality, while others are meant to catch errors. The technology needed to test the business logic differs from testing the presentation layer. Some tests require time and resources to run. 

We can choose from various test types like unit, integration, and end-to-end tests. The Angular ecosystem provides us with specific tolls for each technology, like Jest or Cypress. Tests can be run while coding, before pushing changes, or before deploying the application. You should have a strategy in mind to test your code.