Najważniejsza rzecz jeśli chodzi o pokrycie testami to konsekwencja

Jeżeli z jakiegoś powodu nie możemy osiągnąć 100% pokrycia testami, które części systemu powinniśmy pokryć i w jakim stopniu?

Co będzie dla nas korzystniejsze:

• pokryć jedynie główne pozytywne scenariusze, ale dla wszystkich funkcjonalności
• pokryć jedynie kilka wybranych funkcjonalności, ale w 100%
• postarać się osiągnąć jak najwyższe pokrycie w jak największej ilości funkcjonalności, decydując o tym co pokrywać testami dla każdego przypadku z osobna

Wiele zespołów rozpoczynających pracę z TDD albo pracujących nad projektami typu legacy ma problemy z osiągnięciem pełnego pokrycia testami wszystkich funkcjonalności, tak więc dość często spotykam się z pytaniami podobnymi do powyższych.

Pozwolę sobie podzielić się moją opinią na ten temat.

Największą wartością suity testowej jest pewność, jaką nam zapewnia

Przede wszystkim musimy zrozumieć, jakej informacji dostarcza nam suita testowa.

Intuicyjna odpowiedź jest taka, że gdy suita testowa nie przechodzi, daje nam to informację, że system nie jest poprawny. Jeżeli testy są dobrze napisane, daje nam to dodatkowo precyzyjną informację co konkretnie jest niepoprawne i dlaczego, co pozwala nam szybko naprawić problem. Jest to oczywiście wartościowe, ale nie jest to najważniejsza informacja jaką suita testowa może nam dać.

Suita testowa daje nam najbardziej wartościową informację gdy przechodzi. Zielony pasek mówi nam, że system jest w określonym stopniu [¹] poprawny. Daje nam pewność. Pozwala nam uznać funkcjonalność za gotową. Pozwala nam wdrożyć ją bez obaw na produkcję. Jest to jednak prawdziwe tylko wtedy, gdy możemy zaufać naszej suicie.

Konsekwentna suita testowa, nawet jeśli jest niekompletna, daje nam pewien stopień pewności

Czy możemy zaufać niekompletnej suicie testowej? Tak, ale tylko wtedy, gdy jest niekompletna w konsekwentny sposób.

Oczywiście jeśli pokrycie testami jest jedynie częściowe, prawdopodobnie nie będziemy w stanie automatycznie wdrażać na produkcję bez dodatkowych testów manualnych. Ale jeśli pokrycie testami jest konsekwentne, np. jeśli wiemy, że na pewno wszystkie główne pozytywne ścieżki są pokryte, możemy wtedy ograniczyć nasze manualne testy jedynie do ścieżek negatywnych. Albo nawet możemy zdecydować, że alternatywne ścieżki nie są dla nas krytyczne i że pokrycie wszystkich ścieżek pozytywnych daje nam wystarczającą pewność by zaryzykować wdrożenie na produkcję.

Niekompletna suita testowa nie daje nam wprawdzie pełnej informacji, ale za to na informacji, którą nam daje, możemy polegać i być pewni decyzji, które na jej podstawie podejmujemy.

Niekonsekwentna suita testowa nie daje nam wcale pewności

Jeśli suita testowa jest niekonsekwentna, nie możemy jej ufać, nawet jeżeli pokrycie testami jest relatywnie wysokie. Jeśli funkcjonalności są pokryte testami w przypadkowy sposób, niemożliwe jest określenie, co jest pokryte a co nie. W takim przypadku, przechodząca suita testowa nie daje nam w ogóle użytecznej informacji.

Nie możemy zmniejszyć ilości testów manualnych, ponieważ nie jesteśmy pewni, które części systemu możemy pozostawić zautomatyzowanej weryfikacji. Nie możemy świadomie podjąć decyzji o wdrożeniu na produkcję, ponieważ nie wiemy, których funkcjonalności możemy być pewni a których nie. Tracimy wszystkie korzyści, jakie zielony stan suity testowej normalnie nam daje.

Co pokryć testami by osiągnąć jak największą pewność, jeśli nie możemy mieć pełnego pokrycia?

Bardzo często używam określenia “konsekwencja” – ale co konkretnie rozumiem przez konsekwencję?

Mam na to bardzo prostą regułę: Pokrycie testami jest konsekwentne, jeżeli wszyscy wiedzą, z całkowitą pewnością, które części systemu są pokryte.

Możemy umówić się, że każda funkcjonalność musi mieć przynajmniej w pełni pokrytą główną pozytywną ścieżkę; albo że ściśle zdefiniowany zestaw krytycznych funkcjonalności musi mieć pełne pokrycie a pozostałe, mniej krytyczne funkcjonalnośći mogą nie być pokryte; albo że wszystkie nowe funkcjonalności muszą mieć 100% pokrycia a funkcjonalności legacy nie muszą. Nie ma jednej sztywnej reguły, powinniśmy wybrać to co jest najbardziej wartościowe w naszym konkretnym przypadku. Ale nasz wybór nie może być rozmyty. Jeśli musimy zajrzeć w kod albo zapytać kolegi, by zweryfikować, czy jakaś część systemu jest pokryta, tracimy pewność – a w efekcie, tracimy całą wartość, jaką przechodząca suita testowa nam daje.

Jakie są Twoje doświadczenia z niekompletnymi suitami testowymi? Czy był one dla Ciebie w jakimkolwiek stopniu wartościowe, czy były jedynie dodaktowym obciążeniem? Co robisz, by wyciągnąć jak najwięcej korzyści z takiego częściowego pokrycia? Podziel się swoją opinią w komentarzach poniżej!