Odpowiedź.

Automatyzacja negatywnych scenariuszy jest nieodłączną częścią pełnoprawnego systemu testowania. To są kontrole, podczas których walidowana jest odporność systemu na błędne działania, nieprawidłowe dane, awarie usług i inne nietypowe sytuacje.

Historia pytania:

Wcześniej główną uwagę poświęcano pozytywnym scenariuszom (happy paths), ponieważ łatwiej je automatyzować i utrzymywać. Jednak wymagania dotyczące jakości wzrosły, a coraz więcej błędów pojawia się właśnie na granicach, z błędnymi lub nieoczywiście nieprawidłowymi warunkami. Ich ręczne testowanie szybko się starzeje, a automatyzacja pozwala na śledzenie degradacji.

Problem:

Określenie i pokrycie wszystkich możliwych negatywnych scenariuszy
Prawidłowe sprawdzenie komunikatów o błędach, ważności stanu systemu po nieudanej operacji
Utrzymanie testów przy zmianach logiki biznesowej

Rozwiązanie:

Wyodrębnienie negatywnych scenariuszy i ich systematyzacja (Boundary Value Analysis, Equivalence Partitioning)
Wykorzystanie niestandardowych asercji i walidatorów do sprawdzania treści błędów, kodów HTTP, wyjątków
Automatyczne "oczyszczanie" stanu systemu po teście negatywnym

Kluczowe cechy:

Eksplicytne formułowanie testów dla błędów, wyjątków, nietypowych danych wejściowych
Sprawdzanie komunikatu o błędzie i wewnętrznego stanu systemu
Kontrola efektów ubocznych: po teście negatywnym system powinien pozostawać w spójnym stanie

Pytania z podstępem.

Czy wystarczy tylko sprawdzić, jakie błędy są zwracane podczas testowania negatywnego?

Nie. Ważne jest, aby sprawdzić nie tylko treść błędu, ale również to, że po błędzie nie doszło do zmiany stanu systemu (na przykład, że nie dodano nieprawidłowego wpisu do bazy danych).

Czy należy zautomatyzować wszystkie możliwe negatywne scenariusze?

Nie. Może ich być nieskończoność; należy wydzielić te najprawdopodobniejsze i krytyczne (Boundary Value, Null/Empty, nieprawidłowy typ, SQL injection itp.), a inne w miarę pojawiających się błędów.

Czy można używać tej samej obsługi dla wszystkich negatywnych przypadków?

Nie. Różne negatywne scenariusze wymagają różnych kontroli, obsługi wyjątków i rollbacków, wzorcowe asercje są niewystarczające.

Typowe błędy i antywzorce.

Ignorowanie negatywnych scenariuszy lub pokrywanie ich "dla okazji"
Niewiarygodne sprawdzenie błędu (na przykład, tylko kod 500, ale nie sprawdzenie treści lub efektu ubocznego)
Nieoczyszczone środowisko testowe po awarii testu

Przykład z życia

Negatywny przypadek.

W systemie testuje się tylko ważne scenariusze rejestracji. Rejestracja z pustym emailem nie jest testowana automatycznie. W rezultacie, problem, że można zarejestrować użytkownika z pustym mailem, zostaje zauważony tylko w produkcji.

Zalety:

Łatwa konserwacja testów
Niewielka liczba testów automatycznych i szybki bieg

Wady:

Krytyczne błędy trafiają na produkcję
Rosną koszty napraw i rollbacków

Pozytywny przypadek.

Dla każdego negatywnego scenariusza (brak emaila, nieprawidłowy format, sql injection) istnieje test automatyczny, który wyraźnie sprawdza brak nowego konta i treść komunikatu o błędzie.