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.

The end of our testing journey led us to end-to-end testing. No pun intended. After probing every single aspect of our application, it is time to ensure that all the pieces make what the user expects. We will use Cypress, the most developer-friendly tool that allows us to write tests that interact with the browser, simulating the user experience.

What does end-to-end testing really mean?

 testing is a methodology that tests the entire application from start to finish. This 

 analyzes the application flow from the user's perspective. It aims to replicate real user scenarios and use cases.

Ideally, those tests should be written by the dev team, as they are the ones that know the application better. However, Cypress is easy enough for 

Deploying real-world usable applications has its own challenges, involving using pipes of CI/CD tools. While we will not cover that in this book, at least we will 

 implies, we will test the application as a whole. When things go green, this is a great way to ensure that 

 and is definitely a test you must do before any deployment to production. 

But, this wide way of testing comes with its costs. It is 

 when things go red. Remember, if you use multiple pieces, any failure in any of them will cause the test to fail. But which one? The API? The database? The front-end?

An associated problem with including several servers is the 

 the tests. Each physical layer will add extra time to the test. And, if you are using a cloud provider, you will be paying for that time.

Last but not least, you will need to interact with the database. And, if your tests make any changes to the database, you will need to restore it to its original state. This is not a trivial task, and it will add extra time to the test.

This example uses the whole application and requires all systems to be up and running. It is a good smoke test to ensure that the application at least starts and navigates between remotes.

describe('shell', () => {
  beforeEach(() => cy.visit('/'));

  it('should display welcome message', () => {
    getGreeting().contains('Angular Applications Architecture');
  });
  it('should display the menu', () => {
    getMenu();
  });
  it('should navigate to editor', () => {
    cy.goPage('Editor');
    cy.url().should('include', '/editor');
  });
  it('should navigate back home', () => {
    cy.goPage('Editor');
    cy.goHome();
    cy.url().should('not.include', '/editor');
  });
});

To avoid this kind of problem, we can isolate the front end from the API. This way, we can test without deploying the API and managing any database. This will make the tests 

To do so, we must mock the API responses, a trivial task using Cypress interceptors. You will find samples of how to do it along with the demo code. Remember that this isolation from the server is totally optional. You can still test the solution as a whole. Or better, test some critical paths as a whole and the rest in isolation.

 to mock the API responses. Please read the full chapter and come back here to understand the code after being aware of the used practices.

---
title: Wide tests for the user experience
isPublicLesson: true
useMdx: false
---

# Wide tests for the user experience.

The end of our testing journey led us to end-to-end testing. No pun intended. After probing every single aspect of our application, it is time to ensure that all the pieces make what the user expects. We will use Cypress, the most developer-friendly tool that allows us to write tests that interact with the browser, simulating the user experience.

## What does end-to-end testing really mean?

_End-to-end_ testing is a methodology that tests the entire application from start to finish. This **_black-box_ testing technique** analyzes the application flow from the user's perspective. It aims to replicate real user scenarios and use cases.

Ideally, those tests should be written by the dev team, as they are the ones that know the application better. However, Cypress is easy enough for **QA teams** to use against deployed applications.

Deploying real-world usable applications has its own challenges, involving using pipes of CI/CD tools. While we will not cover that in this book, at least we will **consider API and database implications** of testing end to end.

### Testing the Application as a whole.

As the term _end-to-end_ implies, we will test the application as a whole. When things go green, this is a great way to ensure that **the application is working as expected** and is definitely a test you must do before any deployment to production. 

But, this wide way of testing comes with its costs. It is **hard to know where a problem is** when things go red. Remember, if you use multiple pieces, any failure in any of them will cause the test to fail. But which one? The API? The database? The front-end?

An associated problem with including several servers is the **time and cost of executing** the tests. Each physical layer will add extra time to the test. And, if you are using a cloud provider, you will be paying for that time.

Last but not least, you will need to interact with the database. And, if your tests make any changes to the database, you will need to restore it to its original state. This is not a trivial task, and it will add extra time to the test.

This example uses the whole application and requires all systems to be up and running. It is a good smoke test to ensure that the application at least starts and navigates between remotes.

```typescript
describe('shell', () => {
  beforeEach(() => cy.visit('/'));

  it('should display welcome message', () => {
    getGreeting().contains('Angular Applications Architecture');
  });
  it('should display the menu', () => {
    getMenu();
  });
  it('should navigate to editor', () => {
    cy.goPage('Editor');
    cy.url().should('include', '/editor');
  });
  it('should navigate back home', () => {
    cy.goPage('Editor');
    cy.goHome();
    cy.url().should('not.include', '/editor');
  });
});
```

### Isolating from the API.

To avoid this kind of problem, we can isolate the front end from the API. This way, we can test without deploying the API and managing any database. This will make the tests **faster and cheaper**. 

To do so, we must mock the API responses, a trivial task using Cypress interceptors. You will find samples of how to do it along with the demo code. Remember that this isolation from the server is totally optional. You can still test the solution as a whole. Or better, test some critical paths as a whole and the rest in isolation.

In the following sample, I use **interceptors** to mock the API responses. Please read the full chapter and come back here to understand the code after being aware of the used practices.

```typescript
describe('Given the editor app home page', async () => {
  const page = new CreateDocumentPage();
  const documentsUrl = Cypress.env('apiUrl') + 'documents';
  let postDocumentPayload: any = null;
  let postDocumentOk: any = null;
  before(() => {
    cy.fixture('postDocumentPayload').then((c) => (postDocumentPayload = c));
    cy.fixture('postDocumentOk').then((c) => (postDocumentOk = c));
  });
  beforeEach(() => {
    page.visit();
  });
  describe('When type a title and press the button', () => {
    beforeEach(() => {
      cy.intercept('POST', documentsUrl, {
        statusCode: 201,
      }).as('postDocument');
      page.titleInput().type('My title');
      page.submitButton().click();
    });
    it('Then should post a document with the title', () => {
      cy.wait('@postDocument');
      cy.get('@postDocument')
        .its('request.body')
        .its('title')
        .should('equal', postDocumentPayload.title);
    });
  });
  describe('When the server responds OK', () => {
    beforeEach(() => {
      cy.intercept('POST', documentsUrl, {
        statusCode: 201,
        fixture: 'postDocumentOk',
      }).as('postDocumentError');
      page.titleInput().type('My title');
      page.submitButton().click();
    });
    it('Then should show the response document', () => {
      cy.wait('@postDocumentError');
      page.resultDiv().should('contain.text', postDocumentOk.title);
    });
  });
});
```