როგორ აწერთ NestJS აპლიკაციებისთვის ტესტებს?

Question

Accepted Answer

NestJS უზრუნველყოფს ჩაშენებული **ტესტირების სერვისს (`@nestjs/testing`)**, რომელიც ინტეგრირებულია Jest-თან, და მისი **დამოკიდებულებების შეყვანის არქიტექტურა ტესტირებას განსაკუთრებით სუფთა ხდის** — თქვენ ქმნით ტესტირების მოდულს და აწვდით მოკ-ებს დამოკიდებულებებისთვის. ტესტები იყოფა ერთეულოვან ტესტებად (იზოლირებული) და end-to-end ტესტებად (სრული აპლიკაცია).

## სერვისის ერთეულოვანი ტესტირება (მოკ-ების დამოკიდებულებებით)

```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();
  });
});
```

მთავარი უპირატესობა: NestJS-ის DI საშუალებას გაძლევთ **რეალური დამოკიდებულებების ჩანაცვლება მოკ-ებით** ტესტირების მოდულის provider-ების მეშვეობით — ასე რომ თქვენ ტესტირებთ სერვისს იზოლირებულად, რეალური ბაზის ან გარე სერვისების გარეშე.

## დამოკიდებულებების ადვილი მოკირება

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

ა რა კლასები არ აკონსტრუირებენ მათ დამოკიდებულებებს (DI ამას აკეთებს), მოკ-ების ჩანაცვლება ტრივიალურია — სუფთა ერთეულოვანი ტესტების საფუძველი.

## End-to-end (e2e) ტესტირება — სრული აპლიკაცია 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());
});
```

**E2E ტესტები** ღამტობენ სრულ აპლიკაციას და აკეთებენ რეალურ HTTP მოთხოვნებს (`supertest`-ის მეშვეობით), ზოწავდნენ მთელი ფლოუს (routing → guards → pipes → handler → response) ერთად მუშაობს.

## ტესტირების სტრატეგია

```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.
```

## რატომ აქვს ეს მნიშვნელობა

ტესტირება ესაჭიროა საიმედო აპლიკაციებისთვის, და NestJS-ის არქიტექტურა ამას განსაკუთრებით სუფთა ხდის — იმის გაგება, თუ როგორ გამოიწერთ ტესტებს, მნიშვნელოვანია როგორც კოდის ხარისხისთვის, ისე იმიტომ, რომ ჩარჩო *შედგენილი* ტესტირებისთვის.

ცენტრალური ხედვა ის არის, რომ **დამოკიდებულებების შეყვანა მოკირებას ტრივიალურ ხდის**: რადგან კლასები აცხადებენ მათ დამოკიდებულებებს და DI მათ აწვდის, `@nestjs/testing` მოდული გაძლევთ საშუალებას ნებისმიერი დამოკიდებულება (მონაცემთა ბაზის საწყობები, გარე სერვისები, კონფიგურაცია) მოკით ჩაანაცვლოთ მისი token-ის მეშვეობით, რაც სწრაფ, იზოლირებულ **ერთეულოვან ტესტებს** აკეთებს სერვისების, guards-ის და pipes-ის უკან რეალური ინფრასტრუქტურის გარეშე.

ეს ტესტირებადობა ძირითადი მიზეზია, რის გამოც DI-ზე დაფუძნებული ჩარჩოები, როგორიცაა NestJS, ღირებულნი ითვლებიან.
ank-ას ერთეულოვანი ტესტები, **e2e ტესტები** (სრული აპლიკაციის ღამტობა და რეალური HTTP მოთხოვნების გაკეთება `supertest`-ის მეშვეობით) ზოწავენ მას, რომ მთელი მოთხოვნის pipeline — routing, guards, validation, handlers — სწორად მუშაობს ერთად.

ტესტირების სერვისების (`Test.createTestingModule`, provider overrides მოკირებისთვის) ცოდნა, როგორ დაწეროთ ერთეულოვანი და e2e ტესტები, და გონივრული ტესტირების სტრატეგია (ბევრი სწრაფი იზოლირებული ერთეულოვანი ტესტი, ნაკლები სრული e2e ტესტი, ტესტირების მონაცემთა ბაზა) არის პროფესიონალური NestJS განვითარების ნიშანი.

ეს ასახავს სიმწიფე საინჟინრო პრაქტიკას და გამოიყენებს ზუსტად იმას, რაც NestJS-ის სტრუქტურირებული, DI-ზე დაფუძნებული დიზაინი ღირებულ ხდის, რაც მას მნიშვნელოვან სენიორ-დონის თემას ხდის.