Na początku mojej kariery zawodowej usłyszałem od kierownika, że napisanie jednego testu, który pobiera stronę weryfikuje 90% funkcjonalności.
Wtedy te słowa zaskoczyły mnie i myślałem, że to bardziej forma żartu. Dla mnie napisanie nawet 100 testów byłoby niewystarczające i nie dawałoby mi pewności, że wszystko jest OK. Z perspektywy czasu wiem, że testy to nie dowód, a raczej sieć rybacka – zatrzymają tylko te błędy, na których wykrycie pozwala gęstość oczek.
Skoro nie możemy osiągnąć niemożliwego, to warto w tym miejscu zatrzymać się i zastanowić jaka ilość testów jest odpowiednia.
Wiele firm rozwiązuje tę kwestię poprzez wyznaczenie progu pokrycia testami np. 80%. Osobiście nie jestem zwolennikiem tej metody, ponieważ osiągnięcie, a następnie utrzymanie narzuconego progu skutkuje powstawaniem wielu złożonych testów, które często okazują się przerostem formy nad treścią. Każdy test podnosi koszt projektu, a ich nadmiar niczemu dobremu nie służy.
Podoba mi się perspektywa biznesowa, która postrzega test jak inwestycję. Pisząc test zabiega się o to, by test odzyskał czas jaki został poświęcony na jego utworzenie. Ilość testów jak i ich szczegółowość, powinna iść w parze z wagą i ryzykiem projektu.
Jestem zdania, że najlepszy test to taki, który weryfikuje możliwie wiele przy minimalnym koszcie utrzymania. Może nie jest to idealne podejście, ale wybierając ten kierunek oszczędzam czas tak bardzo potrzebny do analizy i rozwiązywania realnych problemów.
