Testowanie przez warstwy: od kodu do infrastruktury
- data
- kategoria
- Testing
- także w
- CI/CD · Infrastructure · Reliability Engineering
- czytanie
- 1 min / 249 słów
Najgorszy błąd po wdrożeniu rzadko mówi, którego testu zabrakło.
Widać tylko objaw:
testy zielone
deployment zielony
aplikacja startuje
pierwszy prawdziwy request pęka
To nie znaczy, że testy są bez sensu.
Zwykle znaczy, że testowaliśmy za nisko, za wysoko albo obok ryzyka.
Test jako bramka
Test nie jest dowodem, że system jest poprawny.
Jest filtrem:
ten rodzaj błędu nie przeszedł przez tę bramkę
Dlatego rodzaje testów mają sens dopiero wtedy, kiedy wiadomo, gdzie stoją.
Unit test łapie błąd przy decyzji w kodzie.
Integration test łapie błąd na granicy z zależnością.
Contract test pilnuje publicznej umowy.
E2E test sprawdza, czy krytyczna ścieżka naprawdę składa się w całość.
Migration test mówi, czy stan danych nadal da się bezpiecznie zmieniać.
Infrastructure test sprawdza, czy środowisko nie zepsuło założeń aplikacji.
Oś serii
Seria idzie od najtańszej informacji zwrotnej do najdroższej:
kod
|
v
komponent albo moduł
|
v
prawdziwa zależność
|
v
publiczny kontrakt
|
v
pełna ścieżka użytkownika
|
v
dane, wydajność i infrastruktura
Nie chodzi o to, żeby każdy projekt miał wszystkie testy wszędzie.
Chodzi o to, żeby nie używać jednego typu testu do każdego ryzyka.
Jeżeli E2E łapie literówkę w mapperze, test jest za wysoko.
Jeżeli unit test udaje bazę, której zachowanie jest źródłem problemu, test jest za nisko.
Jeżeli pipeline nie sprawdza migracji, rollback może być tylko nadzieją.
Co jest w częściach
Każdy tekst bierze jeden poziom albo jedną bliską grupę nazw i odpowiada na cztery pytania:
co to za rodzaj testu
jaki błąd ma złapać
czego nie widzi
jakim narzędziem zrobiłbym to w moim stacku
Narzędzia są konkretne, ale nie są punktem wyjścia.
Najpierw trzeba nazwać granicę.
Dopiero potem ma sens decyzja, czy użyć Vitest, React Testing Library, Supertest, Testcontainers, Playwright, k6, Conftest, Trivy albo Kyverno.
Na końcu ma z tego wyjść nie lista testów, tylko mapa bramek jakości.
Mniej "mamy dużo testów".
Więcej "wiemy, gdzie dany błąd powinien zostać zatrzymany".