Odpowiedź.

Historia pytania:

Testy smoke (smoke tests, testy "dymne") powstały jako szybki sposób na upewnienie się, że podstawowa funkcjonalność systemu działa po wdrożeniu lub zmianie kodu. Ich ideologia brzmi: "jeśli coś krytycznego jest zepsute, nie ma sensu uruchamiać dokładnych testów". W automatyzacji pierwsze testy smoke były realizowane jako małe ręczne skrypty do sprawdzania uruchomienia aplikacji, przejścia na ekran logowania i podstawowych działań.

Problem:

Największe trudności w automatyzacji testów smoke to właściwa izolacja minimalnego zestawu scenariuszy, duża szybkość wykonania, minimalna zależność od niestabilnych komponentów (np. usług zewnętrznych), a także wizualne i techniczne wsparcie dla ich "lekkości i przejrzystości". Jeśli tego nie zrobimy, automatyzacja smoke staje się albo zbyt ciężka, albo często daje fałszywe alarmy i wymaga dużej konserwacji.

Rozwiązanie:

Minimalizuj liczbę testów smoke: powinny zawierać tylko sprawdzenia najbardziej krytycznych "punktów wejścia" (np. autoryzacja, uruchomienie głównego modułu, dostępność bazy danych).
Przenieś niestabilne kroki i zewnętrzne zależności poza scenariusze smoke lub stabilizuj środowiska z "przeciwwagami".
Używaj tagowania (@smoke, Suite('smoke') itd.) i oddzielnych sekcji w pipeline CI/CD, aby zawsze uruchamiać testy smoke jako pierwsze.

Kluczowe cechy:

Scenariusze smoke powinny być wykonywane szybko i używać tylko najbardziej stabilnej części infrastruktury.
Testy automatyczne klasy smoke nie powinny obejmować szczegółów UX ani skomplikowanego workflow.
Automatyzacja smoke wymaga ścisłej kontroli nad zależnościami i minimalnej ilości kodu wsparcia.

Pytania z zaskoczeniem.

Czy można dodawać do zestawu smoke scenariusze sprawdzające logikę edge-case?

Nie, zestaw smoke służy wyłącznie do sprawdzania żywotności i dostępności głównego systemu, edge-case są tu zbędne, spowolnią wykonanie i skomplikują wsparcie.

Czy w testach smoke należy wdrażać wielopoziomowe przetwarzanie błędów i recovery?

Często błędnie uważa się, że w smoke potrzebne są skomplikowane mechanizmy recovery. W rzeczywistości, jeśli test smoke nie przechodzi - to jest to sygnał o krytycznym problemie, który należy poprawić, a nie "obejść" w teście automatycznym.

Czy testy smoke powinny zależeć od danych pozostawionych przez inne testy?

Nie, testy smoke nie powinny zależeć od żadnych zewnętrznych danych testowych, a tym bardziej od artefaktów innych testów. To jedna z kluczowych zasad ich niezawodności.

Typowe błędy i antywzorce

Przeciążenie testów smoke: zbyt wiele scenariuszy, przekształcanie ich w testy regresyjne.
Duplikacja kodu między testami smoke a zwykłymi testami automatycznymi.
Niejawne zależności: test korzysta z "zabrudzonych" danych/artefaktów z innych scenariuszy.

Przykład z życia

Negatywny przypadek

W zestawie testów smoke wykonano 30 różnych sprawdzeń, część z nich testuje nie tylko uruchomienie systemu, ale także skomplikowane algorytmy, warunki edge-case. Wykonanie testów smoke zajmowało 30 minut, okresowo pewne sprawdzenia padały z powodu niestabilności backendu.

Zalety:

Łatwo dostrzec wąskie Gardła systemu.
Wysokie pokrycie testami zaraz po wdrożeniu.

Wady:

Stracono samego sensu testów smoke: "zieloną" kompilację można uzyskać tylko po długim oczekiwaniu i usunięciu nieistotnych problemów z wdrożeniem systemu w produkcji.
Trudno utrzymać testy i wydzielić rzeczywiste krytyczne awarie.

Pozytywny przypadek

W grupie smoke wprowadzono surowe minimum: logowanie, otwieranie głównej strony, zapytanie do bazy, podstawowy handshake API. Framework smoke działa niezależnie od podstawowej macierzy testowej i zawsze jest pierwszy w pipeline CI/CD. Wyniki - w osobnym czacie i zawsze dostępne do szybkiej diagnostyki.