Test Automation - automatyczne kontrole jakości

Masz komplet testów: jednostkowe, integracyjne, E2E, z atrapami i raportem pokrycia. Ale uruchamiasz je ręcznie. Wystarczy jeden pośpieszny wieczór, żeby ktoś wypchnął zmianę bez sprawdzenia - i cały ten arsenał okaże się bezużyteczny.

Legion nie polega na pamięci wartowników. Ustawia warty stałe: kontrola odbywa się sama, o wyznaczonej porze, niezależnie od tego, kto akurat pełni służbę. Tym właśnie jest automatyzacja testów - przeniesieniem odpowiedzialności z człowieka na maszynę.

Warta stała - testy przy każdej zmianie

Najprostsza warta uruchamia testy przy każdym wypchnięciu kodu:

1# .github/workflows/ci.yml
2name: CI
3on: [push, pull_request]
4
5jobs:
6  test:
7    runs-on: ubuntu-latest
8    steps:
9      - uses: actions/checkout@v4
10      - run: npm ci
11      - run: npm run test
12      - run: npm run test:e2e

Czyta się to jak rozkaz dzienny.

on: [push, pull_request]

npm ci

package-lock.json

npm install

Kluczowe jest to, czego w tym pliku nie widać: każde polecenie musi zwrócić zero. Jeśli

npm run test

Zielona warta, która kłamie

I tu dochodzimy do najważniejszej rzeczy w tej lekcji. Zautomatyzowany test jest wart tyle, ile jego rzetelność - a test asynchroniczny potrafi przechodzić, nie sprawdzając niczego.

Spójrz na te dwie wersje:

1// ŹLE - test kończy się, zanim obietnica się rozstrzygnie
2it('znajduje legionistę', () => {
3  service.findById(1);
4});
5
6// DOBRZE - test czeka na wynik
7it('znajduje legionistę', async () => {
8  const legionary = await service.findById(1);
9  expect(legionary.name).toBe('Marek');
10});

W pierwszej wersji funkcja testowa kończy się natychmiast po wywołaniu metody. Jest uznaje test za zaliczony, bo nic nie rzuciło wyjątku w tym momencie - a metoda dopiero zaczyna pracę. Gdyby zwróciła złe dane albo padła sekundę później, nikt się nie dowie.

Reguła jest krótka i bezwyjątkowa: test dotykający kodu asynchronicznego musi być

async

await

await

Sprawdzanie wyjątków - wariant synchroniczny

Testujemy nie tylko powodzenia. Gdy metoda ma rzucić wyjątek, potrzebujemy asercji, która to potwierdzi:

1it('odrzuca ujemny żołd', () => {
2  expect(() => service.validatePay(-100)).toThrow();
3});

Zwróć uwagę na kształt argumentu: do

expect

expect(service.validatePay(-100))

() => ...

toThrow()

toThrow(BadRequestException)

toThrow('Żołd nie może być ujemny')

Sprawdzanie wyjątków - wariant asynchroniczny

Metoda asynchroniczna nie rzuca wyjątku - zwraca odrzuconą obietnicę. Dlatego

toThrow()

rejects

1it('rzuca NotFoundException dla nieznanego id', async () => {
2  jest.spyOn(repo, 'findOne').mockResolvedValue(null);
3
4  await expect(service.findById(999)).rejects.toThrow(NotFoundException);
5});

Prześledźmy tę asercję po kolei, bo składa się z czterech elementów w ustalonej kolejności.

await expect(

await

service.findById(999)

.rejects

.toThrow(NotFoundException)

Kolejność pracy przy takim teście jest zawsze ta sama: ustaw atrapę tak, by wywołała błąd, wywołaj metodę, użyj

rejects.toThrow()

null

NotFoundException

Bramka lokalna - zanim kod wyjdzie z obozu

Warta w CI wyłapuje wszystko, ale odpowiada po kilku minutach. Szybszą kontrolę stawiamy na własnej maszynie:

1# .husky/pre-commit
2npm run lint
3npm run test -- --onlyChanged

Husky podpina ten skrypt pod

git commit

--onlyChanged

Zauważ podział ról: hak lokalny jest szybki i wybiórczy, warta w CI - wolna i kompletna. Hak ma łapać oczywiste potknięcia, zanim zajmą czyjś czas; nie zastępuje pełnego przebiegu. I to polecam, @name: nie wsadzaj do haka wszystkich testów, bo pierwsze, czego nauczy się zespół, to

--no-verify

Podsumowanie

Warty rozstawione, kontrola dzieje się sama:

• automatyzacja przenosi uruchamianie testów z człowieka na maszynę - decyduje kod wyjścia polecenia,

• on: [push, pull_request]

  wyznacza moment kontroli,

  npm ci

  instaluje dokładnie wersje z

  package-lock.json

  ,
• test dotykający kodu asynchronicznego musi być

  async

  i używać

  await

  - bez tego przechodzi, nie sprawdzając niczego,
• wyjątek synchroniczny:

  expect(() => metoda()).toThrow()

  - do

  expect

  idzie funkcja, nie jej wynik,

• toThrow()

  przyjmuje typ wyjątku lub fragment komunikatu, gdy chcesz zawęzić sprawdzenie,
• odrzucona obietnica:

  await expect(metoda()).rejects.toThrow(NotFoundException)

  - tu przekazujemy samą obietnicę, bez owijania w funkcję,
• kolejność: ustaw atrapę na błąd, wywołaj metodę,

  rejects.toThrow()

  , zweryfikuj typ i komunikat,
• hak

  pre-commit

  z

  --onlyChanged

  daje szybką bramkę lokalną; pełny przebieg zostaw dla CI.

W następnej lekcji zmierzysz się z projektem - kompleksowym otestowaniem systemu zarządzania flotą. A na razie zapamiętaj: warta stała jest warta tyle, ile rzetelność testów, które uruchamia - a test bez

await