Traktuj testy jako dowody

Zacznij od wymagania

Testy są dowodami dotyczącymi konkretnych twierdzeń. Pomyślne uruchomienie testów nie potwierdza wszystkich właściwości oprogramowania. Zanim je zlecisz, określ istotne zachowanie i błąd, który ma wykryć każda kontrola.

W fikcyjnym eksporcie organizacji głównym wymaganiem jest izolacja danych. Użytkownik organizacji A nie może otrzymać rekordów organizacji B. Test samego udanego pobrania nie potwierdza tego wymagania.

Poproś agenta o wyjaśnienie związku między wymaganiem a asercją. Ułatwia to wykrywanie brakujących przypadków, zanim zestaw testów znacznie się rozrośnie.

Wybierz odpowiedni zakres testu

Test jednostkowy może szybko sprawdzić małe przekształcenie. Test integracyjny bada współpracę komponentów. Test end-to-end może sprawdzić ważną sekwencję działań użytkownika we wdrożonej lub reprezentatywnej aplikacji.

Użyj najwęższego zakresu dostarczającego potrzebnych dowodów. Formatter nie potrzebuje pełnego testu przeglądarkowego dla każdego wejścia. Granica autoryzacji może wymagać rzeczywistej trasy i ścieżki dostępu do danych. Istotna interakcja w przeglądarce wymaga dowodów dotyczących wyrenderowanego interfejsu.

Żaden stały udział typów testów nie pasuje do każdego systemu. Wybieraj na podstawie błędu do wykrycia i kosztu utrzymania kontroli.

Unikaj wspólnego błędnego założenia

Agent może napisać implementację i testy na podstawie tego samego nieporozumienia. Oba mogą być zgodne ze sobą, choć wymaganie pozostaje niespełnione.

Załóżmy, że implementacja filtruje rekordy według identyfikatora organizacji podanego w żądaniu. Test używa tego samego identyfikatora dla zalogowanego użytkownika i żądania. Test przechodzi. Brakuje przypadku, w którym użytkownik żąda identyfikatora innej organizacji.

Dodaj ten przypadek, korzystając z rzeczywistej zaufanej tożsamości i ścieżki autoryzacji. Mock zawsze zwracający „dozwolone” nie potwierdza izolacji tenantów. Potwierdza tylko zachowanie po udanej autoryzacji.

Sprawdź, czy test może nie przejść

Dla znanego błędu uruchom nowy test regresji na wadliwej wersji na odizolowanym branchu. Potwierdź, że nie przechodzi z zamierzonego powodu. Następnie zastosuj poprawkę i uruchom go ponownie.

Test, który nie przechodzi z powodu problemu z załadowaniem danych testowych, nie dowodzi jeszcze niczego o zachowaniu biznesowym. Sprawdź przyczynę niepowodzenia, nie tylko kod zakończenia.

Przy szerszych zmianach testy mutacyjne mogą pomóc ocenić, czy wybrane zmiany kodu powodują niepowodzenie testów. Mają koszt i nie zastępują przeglądu wymagań. Używaj ich tam, gdzie dodatkowy dowód wspiera istotną decyzję.

Powiąż dowody ze zmianą

Uruchom właściwe kontrole na końcowej wersji. Zapisz pominięte kontrole i powody pominięcia. Wynik wcześniejszego commita może przestać obowiązywać po poprawce z przeglądu.

Dbaj o zrozumiałość testów. Wybieraj jawne przygotowanie i asercję zamiast rozbudowanego helpera ukrywającego istotny warunek. Usuwaj zbędne kontrole, jeśli zwiększają koszt utrzymania bez wykrywania innego błędu.

Recenzent powinien umieć powiedzieć, co testy potwierdzają i co pozostaje niepewne. Takie wyjaśnienie jest bardziej przydatne niż duża liczba testów.