E2E Testing - simulating a full campaign

The catapult fires, the parts fit together. But a campaign is not one shot: the scouts find the enemy, a messenger carries the order, the legion forms up, the machines strike, the camp packs at dusk. Checking each stage separately will not tell you whether the whole expedition reaches its end.

An E2E test - end to end - walks that road in full. It starts a real application, sends real requests and checks what a user would see. No doubles: if validation, authentication or a database write fails along the way, the test catches it.

Where E2E tests live

We keep E2E tests apart from the rest, because they have their own configuration and their own pace:

1test/
2  app.e2e-spec.ts
3  jest-e2e.json

The test file carries the

.e2e-spec.ts

test/jest-e2e.json

npm run test:e2e

Four steps to a running application

Preparing the application always goes the same way, and the order is worth knowing:

1describe('Legions (e2e)', () => {
2  let app: INestApplication;
3
4  beforeAll(async () => {
5    const moduleFixture = await Test.createTestingModule({
6      imports: [AppModule],
7    }).compile();
8
9    app = moduleFixture.createNestApplication();
10    app.useGlobalPipes(new ValidationPipe());
11    await app.init();
12  });
13
14  afterAll(async () => {
15    await app.close();
16  });
17});

Step one:

Test.createTestingModule({ imports: [AppModule] })

AppModule

Step two:

.compile()

Step three:

createNestApplication()

Step four:

await app.init()

Between steps three and four there is room for one thing that is easily forgotten: the global elements normally configured in

main.ts

ValidationPipe

main.ts

Walking the whole road

With the application in place, we send requests with the supertest library - the same one you met in integration tests:

1it('creates a legion and lets you fetch it', async () => {
2  const created = await request(app.getHttpServer())
3    .post('/legions')
4    .send({ name: 'Legio I' })
5    .expect(201);
6
7  await request(app.getHttpServer())
8    .get(`/legions/${created.body.id}`)
9    .expect(200)
10    .expect((res) => {
11      expect(res.body).toEqual({
12        id: created.body.id,
13        name: 'Legio I',
14      });
15    });
16});

The chain reads like a description of a conversation with the server:

request(app.getHttpServer())

.post('/legions')

.send({...})

.expect(201)

But the most interesting part is elsewhere: the second request uses the result of the first. We saved a legion and then fetched it by the identifier the server returned. That is what no lower-level test will do - we are checking not a single endpoint but a user scenario made of several steps.

toEqual versus toBe

In that last assertion we used

toEqual

1expect(res.body).toEqual({ id: 1, name: 'Legio I' });   // passes
2expect(res.body).toBe({ id: 1, name: 'Legio I' });      // fails

The difference is fundamental.

toBe

toBe

toEqual

toBe

When not E2E - a controller in isolation

The full road gives the most confidence but costs the most time. When you want to check the controller's own logic - whether it passes the right arguments on - build it with a mocked service:

1const mockService = { findAll: jest.fn().mockResolvedValue([]) };
2
3const module = await Test.createTestingModule({
4  controllers: [LegionsController],
5  providers: [{ provide: LegionsService, useValue: mockService }],
6}).compile();
7
8const controller = module.get(LegionsController);
9
10it('passes the status filter to the service', async () => {
11  await controller.findAll('active');
12
13  expect(mockService.findAll).toHaveBeenCalledWith({ status: 'active' });
14});

The service is a double here, so we examine the controller alone. The

toHaveBeenCalledWith

Choosing between the two comes down to one question: am I checking one layer's logic or the road through all of them. E2E for scenarios, isolation for details.

Summary

The campaign has travelled the whole road:

• an E2E test starts a real application and walks a request's full road, with no doubles,
• files carry the

  .e2e-spec.ts

  suffix, the configuration sits in

  test/jest-e2e.json

  , and

  npm run test:e2e

  runs them,
• four preparation steps:

  createTestingModule({ imports: [AppModule] })

  ,

  .compile()

  ,

  createNestApplication()

  ,

  await app.init()

  ,
• the global elements from

  main.ts

  do not come in automatically -

  ValidationPipe

  and filters must be added, or the test passes falsely,
• the supertest chain:

  request(app.getHttpServer())

  ,

  .post('/address')

  ,

  .send({...})

  ,

  .expect(201)

  ,
• E2E's strength is a multi-step scenario where each request uses the previous one's result,

• toEqual

  compares structure and values deeply - the choice for objects;

  toBe

  checks identity and suits only primitives,
• to examine a controller alone, swap the service for a double and use

  toHaveBeenCalledWith

  to check the arguments passed,

• app.close()

  in

  afterAll

  is mandatory.

In the next lesson we will look at the doubles themselves - you will meet the four kinds and the difference between

jest.fn()

jest.spyOn()