Kiedy prowadzimy testy automatyczne (i nie tylko), napotkanie na defekt lub nieoczekiwane zachowanie aplikacji może przypominać próbę przejścia przez ścianę. Cały proces, który do tej pory wydawał się płynną rzeką, nagle uderza o przeszkodę i traci swój rytm. Jeszcze bardziej przytłaczające jest, to gdy zgłosimy ten problem zespołowi, a on zdecyduje się go na razie nie naprawiać.
Tworzenie testów z myślą o ich niepowodzeniu
Co robić, gdy musisz pisać testy automatyczne w takiej sytuacji? Czy omijać problematyczne miejsce? Pozwolić testom na ciągłe zawieszanie się na tym samym błędzie? A może podjąć próbę eskalacji problemu?
Jednym z rozwiązań jest pisanie testów, które są zaprojektowane tak, aby przechodzić, ale jednocześnie są skonstruowane w taki sposób, by umożliwić identyfikację nowych problemów, jeśli te się pojawią. Taka strategia oznacza akceptację zaistniałego stanu jako „nowej normy” i dostosowanie do niej testów. Gdy testy zawiodą, będzie to sygnał, że pojawiło się coś nowego, co wymaga naszej uwagi.
Wzbogacanie testów o kontekst i dokumentację
Zaprojektowanie testów, które mają zawodzić, to nie tylko kwestia technicznej implementacji, ale także komunikacji i dokumentacji. Warto pamiętać, że informacja, którą zwracają nam nasze testy, musi być czytelna i zrozumiała również dla innych członków zespołu, którzy mogą nie mieć takiej wiedzy technicznej jak testerzy.
Dlatego ważne jest, aby każdy test był odpowiednio udokumentowany. Można to zrobić na kilka sposobów – poprzez dodawanie opisów w kodzie, tworzenie notatek TODO, które są łatwe do odnalezienia w środowisku IDE, czy też opisywanie testów w systemach śledzenia błędów, takich jak Jira. To pomoże w przyszłości uniknąć niejasności i oszczędzi czas, który inaczej musiałby być poświęcony na rozszyfrowywanie, co dany test miał na celu i dlaczego został napisany w taki, a nie inny sposób.
Prace konserwacyjne
Projektowanie testów z myślą o ich ewentualnym niepowodzeniu to strategia, która wymaga regularnej konserwacji i aktualizacji. Ważne jest, aby regularnie przeglądać i aktualizować TODOs oraz inne notatki, aby upewnić się, że są nadal aktualne i odnoszą się do istniejących defektów. Regularne przeglądy pomagają również zidentyfikować, czy problem, który niegdyś był uznany za defekt, nadal istnieje, czy też został już rozwiązany lub stał się nieistotny z powodu innych zmian w aplikacji.
Ostatecznie, projektowanie testów z myślą o ich niepowodzeniu to strategia, która pomaga zmniejszyć frustrację związaną z ciągłym widokiem testów zawieszających się na tych samych problemach. Przez akceptację rzeczywistości i dostosowanie do niej naszych testów, jesteśmy w stanie lepiej kontrolować proces testowania i uczynić go bardziej efektywnym.
Inspiracje:
How to test when you know a bug won’t be fixed