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.

Let’s have an inside-out approach to testing. Starting with laser-focused tests for the business logic and then moving to integration tests for the use cases.

As I said in the last lesson, I prefer the term narrow testing over unit testing because I think it is more descriptive of the goal of the tests and does not set any expectations about what a unit is. Despite that, you and I can use interchangeably the terms unit testing and narrow testing.

But what is a narrow test? A narrow test is a test that focuses on a single piece of business logic and does not care about the rest of the system. 

Before we start writing tests, we need to choose some tools. Traditionally, Angular applications were tested with Karma and Jasmine. But, in the last years, Jest has become a popular alternative.

The main reasons for this are that Jest is faster, has a better developer experience, and has wider usage by not being specific to a single framework.

In this book, we are going to use Jest, but you can use Karma and Jasmine if you prefer because the concepts are the same, and the syntax is very similar.

By using the Nx DevTools, we have installed and configured Jest for free. But if you want to do it manually, you must know a few tricky steps.

First of all, install the Jest dependencies with their Typescript type definitions. Then, add the jest-preset-angular package, a set of Jest configurations that is specific to Angular.

npm install jest @types/jest ts-jest jest-preset-angular --save-dev

Configuration vastly depends on the current version you use. Look for inspiration in my files with the 

 configuration that pre-builds libraries and applications before running the tests. They are very similar to their Karma counterparts.

I chose what projects are prone to have logic errors and made them candidates for unit testing. In 

 file, you can find the following almost standard scripts:

{
  "domain:unit": "nx test shared-domain --watch",
  "editor-domain:unit": "nx test editor-domain --watch",
  "commands:unit": "nx test shared-commands --watch",
}

Time to write code. I will start with the domain libraries because they are the most important ones and have fewer dependencies, making them easier to test. Win-win.

Here, you can find an excerpt of the tests. For the full code, please refer to the repository.

The first sample is a simple test for a pure function. It is a function that does not depend on any external resource, and always returns the same result for the same input.

Getting familiar with the Jest syntax is easy. The 

 function is used to group tests, and the 

describe('The getSlug function', function () {
  it('should return the correct slug for each edge cases', function () {
    const SAMPLE_CASES = [
      ['This is a Test 123', 'this_is_a_test_123'],
      ['This is Español', 'this_is_espa-ol'],
      ['This is a Test with spaces', 'this_is_a_test_with_spaces'],
      ['This has inv@lid chars', 'this_has_inv-lid_chars'],
    ];
    SAMPLE_CASES.forEach(([source, expected]) => {
      const actualSlug = getSlug(source);
      expect(actualSlug).toBe(expected);
    });
  });
});

The second sample is a test for a class. Again, in this case, I chose a class that does not depend on any external resource and always returns the same result for the same input. It is very similar to the previous one.

I want to introduce some practices I use in my tests, like the AAA pattern and naming conventions. I like to use the 

. It is a common practice in the testing community. Also, I use the INPUT

* constants to define the input values and the `EXPECTED

*` constants to define the expected values. Both in SCREAMING_SNAKE_CASE.

describe('The CommandStore class', () => {
  const INPUT_NULL = NULL_DTO;
  const INPUT_RESULT = { id: 'input', timestamp: new Date(0) };
  const INPUT_ERROR = { message: 'error' };
  let commandStoreSUT: CommandStore<DTO>;
  beforeEach(() => {
    // Arrange
    commandStoreSUT = new CommandStore(INPUT_NULL);
  });
  it('should be instantiable', () => {
    expect(commandStoreSUT) // Act
      .toBeTruthy(); // Assert
  });
  it('should set correct states when setStarted is called', () => {
    // Act
    commandStoreSUT.setStarted();
    // Assert
    expect(commandStoreSUT.isWorking()).toBe(true);
    expect(commandStoreSUT.result()).toBe(INPUT_NULL);
    expect(commandStoreSUT.error()).toBeNull();
  });
});

---
title: Narrow tests for business logic
isPublicLesson: false
useMdx: false
---

# Narrow tests for business logic.

Let’s have an inside-out approach to testing. Starting with laser-focused tests for the business logic and then moving to integration tests for the use cases.

As I said in the last lesson, I prefer the term narrow testing over unit testing because I think it is more descriptive of the goal of the tests and does not set any expectations about what a unit is. Despite that, you and I can use interchangeably the terms unit testing and narrow testing.

But what is a narrow test? A narrow test is a test that focuses on a single piece of business logic and does not care about the rest of the system. 

## Tools for unit testing.

Before we start writing tests, we need to choose some tools. Traditionally, Angular applications were tested with Karma and Jasmine. But, in the last years, Jest has become a popular alternative.

The main reasons for this are that Jest is faster, has a better developer experience, and has wider usage by not being specific to a single framework.

In this book, we are going to use Jest, but you can use Karma and Jasmine if you prefer because the concepts are the same, and the syntax is very similar.

### Jest, installation, and configuration.

By using the Nx DevTools, we have installed and configured Jest for free. But if you want to do it manually, you must know a few tricky steps.

First of all, install the Jest dependencies with their Typescript type definitions. Then, add the jest-preset-angular package, a set of Jest configurations that is specific to Angular.

```bash
npm install jest @types/jest ts-jest jest-preset-angular --save-dev
```

Configuration vastly depends on the current version you use. Look for inspiration in my files with the `jest` or `tsconfig.spec` literals in their names.

The Angular `project.json` file has the `test` configuration that pre-builds libraries and applications before running the tests. They are very similar to their Karma counterparts.

I chose what projects are prone to have logic errors and made them candidates for unit testing. In `package.json` file, you can find the following almost standard scripts:

```json
{
  "domain:unit": "nx test shared-domain --watch",
  "editor-domain:unit": "nx test editor-domain --watch",
  "commands:unit": "nx test shared-commands --watch",
}
```

### Writing unit tests.

Time to write code. I will start with the domain libraries because they are the most important ones and have fewer dependencies, making them easier to test. Win-win.

:::note
Here, you can find an excerpt of the tests. For the full code, please refer to the repository.
:::

-   **Shared Domain**: `new-docs\libs\shared\domain\src\lib\utils\identifier.functions.test.ts`

The first sample is a simple test for a pure function. It is a function that does not depend on any external resource, and always returns the same result for the same input.

Getting familiar with the Jest syntax is easy. The `describe` function is used to group tests, and the `it` function is used to define a test. The `expect` function is used to make assertions.

```typescript
describe('The getSlug function', function () {
  it('should return the correct slug for each edge cases', function () {
    const SAMPLE_CASES = [
      ['This is a Test 123', 'this_is_a_test_123'],
      ['This is Español', 'this_is_espa-ol'],
      ['This is a Test with spaces', 'this_is_a_test_with_spaces'],
      ['This has inv@lid chars', 'this_has_inv-lid_chars'],
    ];
    SAMPLE_CASES.forEach(([source, expected]) => {
      const actualSlug = getSlug(source);
      expect(actualSlug).toBe(expected);
    });
  });
});
```

-   **State**: `new-docs\libs\shared\state\src\lib\command.store.test.ts`

The second sample is a test for a class. Again, in this case, I chose a class that does not depend on any external resource and always returns the same result for the same input. It is very similar to the previous one.

I want to introduce some practices I use in my tests, like the AAA pattern and naming conventions. I like to use the `SUT` acronym to refer to the _System Under Test_. It is a common practice in the testing community. Also, I use the INPUT_\* constants to define the input values and the \`EXPECTED_\*\` constants to define the expected values. Both in SCREAMING_SNAKE_CASE.

```typescript
describe('The CommandStore class', () => {
  const INPUT_NULL = NULL_DTO;
  const INPUT_RESULT = { id: 'input', timestamp: new Date(0) };
  const INPUT_ERROR = { message: 'error' };
  let commandStoreSUT: CommandStore<DTO>;
  beforeEach(() => {
    // Arrange
    commandStoreSUT = new CommandStore(INPUT_NULL);
  });
  it('should be instantiable', () => {
    expect(commandStoreSUT) // Act
      .toBeTruthy(); // Assert
  });
  it('should set correct states when setStarted is called', () => {
    // Act
    commandStoreSUT.setStarted();
    // Assert
    expect(commandStoreSUT.isWorking()).toBe(true);
    expect(commandStoreSUT.result()).toBe(INPUT_NULL);
    expect(commandStoreSUT.error()).toBeNull();
  });
});
```

### Running tests while coding.

The beauty of narrow-unit tests is that they are fast. So you can run them while coding and get immediate feedback. To do so, you can use the `--watch` flag in the `nx test` command.

```bash
# nx test shared-domain --watch
npm run domain:unit
# nx test shared-commands --watch
npm run commands:unit
```

Running the test while coding is a great way to find any defect as soon as possible. But you can go further by writing your tests before the code. This is called _Test Driven Development_, or **TDD**.

The benefits of TDD are significant. It helps you think about your code’s design, and write code that is easy to test. A double win. But, it is not easy to do because it requires practice and discipline to do it right. 

It is beyond the scope of this book to teach it properly. So, if you are new to testing, I recommend you start writing tests after the code and run them while coding. Then, when you feel comfortable, you can try TDD.

## Isolation and unit testing

Until now, I have been talking about unit testing but have not explained what a unit is. A unit is a piece of code that can be tested in isolation. What leads us to the concept of isolation?

Isolation is the ability to test a piece of code without depending on any external resource. Almost all the code that we write depends on other resources. A function calling another function, a class instantiating another class, a component using a service, etc.

So, how can we test a piece of code that depends on other resources? The answer is using **doubles**. 

### When and how to use doubles.

Doubles are objects that replace the actual dependencies in the tests. And what about dependencies? Are all of them equal? No, they are not. I like to classify collaborators in two dimensions: cost of execution and reliability.

The execution cost is the time and resources taken. Reliability is the confidence that the dependency works.