Jak testujesz aplikacje NestJS?

Question

Accepted Answer

NestJS udostępnia wbudowane **narzędzie testowe (`@nestjs/testing`)** zintegrowane z Jestem, a jego **architektura wstrzykiwania zależności sprawia, że testowanie jest szczególnie przejrzyste** — tworzysz moduł testowy i wstrzykujesz mock'i dla zależności. Testy dzielą się na testy jednostkowe (izolowane) i testy e2e (pełna aplikacja).

## Testowanie usługi jednostkowej (z mock'owanymi zależnościami)

```ts
import { Test } from "@nestjs/testing";

describe("UsersService", () => {
  let service: UsersService;
  let mockRepo = { find: jest.fn(), save: jest.fn() };

beforeEach(async () => {
    const module = await Test.createTestingModule({
      providers: [
        UsersService,
        // inject a MOCK for the repository — no real database needed
        { provide: getRepositoryToken(User), useValue: mockRepo },
      ],
    }).compile();

service = module.get<UsersService>(UsersService);
  });

it("returns all users", async () => {
    mockRepo.find.mockResolvedValue([{ id: 1, name: "Ann" }]);
    const result = await service.findAll();
    expect(result).toHaveLength(1);
    expect(mockRepo.find).toHaveBeenCalled();
  });
});
```

Kluczowa zaleta: DI w NestJS pozwala ci **zamienić rzeczywiste zależności na mock'i** poprzez dostawców modułu testowego — dzięki temu testujesz usługę w izolacji, bez rzeczywistej bazy danych czy usług zewnętrznych.

## Łatwe mock'owanie zależności

```ts
// provide a fake for ANY dependency by its token
{ provide: EmailService, useValue: { send: jest.fn() } }
{ provide: ConfigService, useValue: { get: () => "test-value" } }
```

Ponieważ klasy nie konstruują swoich zależności (robi to DI), zastępowanie mock'ów jest trywialne — fundamentem czystych testów jednostkowych.

## Testowanie end-to-end (e2e) — pełna aplikacja przez HTTP

```ts
import * as request from "supertest";

describe("Users (e2e)", () => {
  let app: INestApplication;

beforeAll(async () => {
    const module = await Test.createTestingModule({
      imports: [AppModule],        // the whole app
    }).compile();
    app = module.createNestApplication();
    await app.init();
  });

it("GET /users", () => {
    return request(app.getHttpServer())   // make a real HTTP request
      .get("/users")
      .expect(200)
      .expect(res => expect(res.body).toBeInstanceOf(Array));
  });

afterAll(async () => await app.close());
});
```

**Testy E2E** uruchamiają pełną aplikację i wykonują rzeczywiste żądania HTTP (via `supertest`), weryfikując, że cały przepływ (routing → guards → pipes → handler → response) działa razem.

## Strategia testowania

```text
Unit tests  → services, guards, pipes in isolation (mock dependencies) — fast, numerous
Integration → a controller + its real service together via the testing module
E2E tests   → full app over HTTP (supertest) — verify real request flows, fewer
Use a TEST database (or mocks) for e2e; override providers for external services.
```

## Dlaczego to ważne

Testowanie jest niezbędne dla niezawodnych aplikacji, a architektura NestJS sprawia, że jest to niezwykle przejrzyste — umiejętność testowania jest ważna zarówno dla jakości kodu, jak i dlatego że framework jest *zaprojektowany* z myślą o testowalności.

Centralnym spostrzeżeniem jest to, że **wstrzykiwanie zależności sprawia, że mock'owanie jest trywialne**: ponieważ klasy deklarują swoje zależności, a DI je dostarcza, moduł `@nestjs/testing` pozwala ci zamienić dowolną zależność (repozytoria bazodanowe, usługi zewnętrzne, konfiguracja) na mock poprzez jej token, umożliwiając szybkie, izolowane **testy jednostkowe** usług, guard'ów i pipe'ów bez rzeczywistej infrastruktury.

Ta testowalność to jeden z głównych powodów, dla których frameworki oparte na DI, takie jak NestJS, są cenione.

Uzupełniając testy jednostkowe, **testy e2e** (uruchamianie pełnej aplikacji i wykonywanie rzeczywistych żądań HTTP via `supertest`) weryfikują, że cały pipeline żądań — routing, guardy, walidacja, handlery — działają razem prawidłowo.

Znajomość narzędzi testowych (`Test.createTestingModule`, override'ów dostawców do mock'owania), umiejętność pisania zarówno testów jednostkowych, jak i e2e, oraz rozsądna strategia testowania (wiele szybkich izolowanych testów jednostkowych, mniej pełnych testów e2e, testowa baza danych) to cecha profesjonalnego rozwoju NestJS.

Od tego zależy dojrzała praktyka inżynierska i wykorzystanie dokładnie tego, co sprawia, że strukturalna, oparta na DI konstrukcja NestJS jest cenna, czyniąc to ważnym tematem na poziomie senior.