Regression tests i smoke tests: bramka przed wydaniem
- data
- kategoria
- Testing
- także w
- CI/CD · Reliability Engineering
- czytanie
- 2 min / 462 słów
Nie każdy test nazywa się od miejsca w architekturze.
Unit test mówi, jak mała jest jednostka.
Integration test mówi, że sprawdzamy granicę między częściami.
Regression test mówi coś innego:
ten błąd już raz się wydarzył
To jest nazwa od powodu istnienia testu.
Regression tests
Regression test powstaje po błędzie albo przy ryzyku powrotu starego zachowania.
Najpierw jest objaw:
użytkownik bez uprawnień widzi przycisk
faktura liczy VAT dwa razy
retry tworzy duplikat zamówienia
cache zwraca dane innego tenant
Potem jest poprawka.
Potem powinien zostać test, który zamyka tę drogę.
Regression test może być unit testem, integration testem, API testem albo E2E.
Nazwa regression nie mówi, na którym poziomie test działa.
Mówi, że chroni przed powrotem błędu.
Co się dzieje, kiedy ich nie ma
Bez regression tests zespół naprawia ten sam problem więcej niż raz.
Bug wraca po refactorze.
Wraca po zmianie zależności.
Wraca po migracji.
Wraca, bo nikt nie zapisał w kodzie, czego system ma już nigdy nie zrobić.
Najgorsze jest to, że drugi raz taki błąd jest droższy psychologicznie.
Nie tylko system zawiódł.
Zawiódł też proces uczenia się po awarii.
Smoke tests
Smoke test odpowiada na prostsze pytanie:
czy system w ogóle żyje?
To nie jest pełny test jakości.
To szybka bramka po buildzie, deploymencie albo przełączeniu ruchu.
Przykłady:
aplikacja startuje
health endpoint odpowiada
strona główna się renderuje
logowanie nie zwraca 500
worker pobiera wiadomość z kolejki
nowa wersja ma dostęp do bazy
Smoke test ma być krótki.
Jeżeli trwa długo i sprawdza dużo przypadków, przestaje być smoke testem.
Sanity tests
Sanity test jest blisko smoke testu, ale zwykle dotyczy konkretnej zmiany.
Po poprawce w płatnościach można sprawdzić minimalną ścieżkę płatności.
Po zmianie routingu można sprawdzić jeden request przez nową trasę.
Po migracji konfiguracji można sprawdzić, czy aplikacja czyta właściwe zmienne.
Sanity test nie zastępuje pełnej regresji.
Ma odpowiedzieć, czy podstawowe założenie po zmianie nadal ma sens.
Gdzie stoją w pipeline
Smoke tests często stoją wcześnie po buildzie albo zaraz po deploymencie.
Regression tests są rozłożone po różnych poziomach.
unit regression test
integration regression test
API regression test
E2E regression test
To ważne, bo nie warto robić E2E tylko dlatego, że błąd był produkcyjny.
Jeżeli produkcyjny błąd wynikał z jednej funkcji, najlepszy regression test może być unit testem.
Test ma zamknąć najkrótszą drogę powrotu błędu, nie odtwarzać cały incydent.
Narzędzie ze stacka
Do smoke tests w tym stacku użyłbym GitHub Actions jako bramki oraz małego zestawu testów z Supertest albo Playwright.
Dla backendu smoke test może odpalić aplikację Node i sprawdzić:
health endpoint
połączenie z bazą
podstawowy endpoint API
Dla frontu smoke test w Playwright może sprawdzić, czy aplikacja się renderuje i czy logowanie nie kończy się błędem.
Regression tests pisałbym tym narzędziem, które najkrócej zamyka błąd: Vitest, Supertest albo Playwright.
To nie jest osobny runner, tylko decyzja o poziomie.
Kiedy są źle ustawione
Smoke test jest źle ustawiony, kiedy próbuje być pełnym testem systemu.
Regression test jest źle ustawiony, kiedy nie wiadomo, jaki błąd zamyka.
W obu przypadkach test zaczyna istnieć jako rytuał.
Jest w pipeline, ale nikt nie pamięta, przed czym chroni.
Dobre pytanie przy review brzmi:
jeżeli ten test usuniemy, jaki błąd znowu może przejść?
Jeżeli odpowiedź jest konkretna, test ma sens.
Jeżeli odpowiedź brzmi "bo coverage", test prawdopodobnie wymaga przemyślenia.
Następna grupa testów dotyczy miejsca, w którym rollback bywa najtrudniejszy: danych.