"Testować albo nie testować; oto jest pytanie:
Czy szlachetniejszym jest znosić świadomie
Losu wściekłego pociski i strzały,
Czy za broń porwać przeciw morzu bugów,
Aby odparte znikły?"
- William Shakespeare, Hamlet *
Od kilkunastu lat każdą wolną chwilę poświęcam głębokim studiom literatury, filozofii i sztuki, aby dociec prawdy na temat natury testów oprogramowania. Szukam znaków z przeszłości, które pomogłyby dzisiejszym testerom wyznaczyć kierunek swojego postępowania. Ludzkość od wieków próbuje odpowiedzieć sobie na jedno, niezwykle istotne, pytanie – jak stwierdzić, czy coś działa czy nie działa. Dzisiaj postaramy się zgłębić ten problem ścierając ze sobą poglądy dwóch wielkich myślicieli: św. Tomasza z Akwinu oraz Kartezjusza. Spróbujemy zastanowić się czy istnieje odpowiedź na zadane w tytule tego artykułu pytanie. A wszystkim wytrwałym, którzy dotrwają do końca tego tekstu, przedstawię pewną heurystykę wywodzącą się wprost z polskiej tradycji ludowej, która pozwala w lepszy lub gorszy sposób oszacować ilość potrzebnych testów dla dowolnego oprogramowania. Przejdźmy zatem do cytatów:
For those with faith, no tests are necessary; for those without it, no tests will suffice. - Św. Tomasz z Akwinu **
Należy wierzyć jedynie temu, cośmy doskonale przetestowali i w co nie można wątpić. - Kartezjusz ***
Pierwszym co rzuca się w oczy, czytając dwa powyższe cytaty, jest fakt, że przedstawiają one zupełnie sprzeczne ze sobą podejścia. Można by powiedzieć, że pierwszy z nich uznaje naturę testów za niedeterministyczną, a drugi przeciwnie – deterministyczną.
Św. Tomasz z Akwinu przytomnie zauważa, że osoby, które wierzą w swój zespół, w swoich programistów, w product ownera, w scruma, nie potrzebują tak naprawdę żadnych testów – bo i po co? A wszelkie niedowiarki, fanatycy waterfalla, nieważne, ile by testów nie zostało wykonanych, czy to manualnych, czy automatycznych, ile osób by to testowało i jak dokładna regresja byłaby wykonana przed każdym deploymentem – dosłownie nic nie będzie ich w stanie ponad wszelką wątpliwość przekonać, że produkt działa. Zawsze bowiem istnieje chociaż cień niepewności, że coś jednak szwankuje. Może przecież wystąpić jakaś zależność czasowa, jakiś race-condition, który może objawić się dopiero za jakiś czas w specyficznych warunkach. Natura testów według św. Tomasza z Akwinu jest ewidentnie niedeterministyczna.
Kartezjusz jednak - przez wielu uznawany za ojca filozofii nowożytnej - uważa coś zgoła odmiennego. Twierdzi on, że możemy wierzyć jedynie temu oprogramowaniu, które przetestowaliśmy w sposób doskonały, kompletny, ponad wszelką wątpliwość. Współcześnie taki stan nazywamy stuprocentowym pokryciem testami. Jest to stan niezwykle rzadki, trudny i kosztowny do uzyskania, ale według Kartezjusza jednak możliwy. Kartezjusz odrzuca wszelkie aspekty wiary w ocenie działania czy nie działania oprogramowania, kładzie natomiast nacisk na pragmatyzm i doskonałość rzemiosła testerskiego. Nasza wiara w team także tutaj nie ma wielkiego znaczenia, działanie software’u jest bowiem czymś niezależnym od swoich twórców.
Filozofia i mędrcy z przeszłości, jak to zwykle bywa, sprawiają, że wiemy jeszcze mniej niż przedtem. Dlatego postaram się przedstawić trzeci, bardziej wyważony pogląd - czyli jak sprawy się mają w oczach praktyka. A na koniec obiecana heurystyka, która zawsze daje jakieś rezultaty, a nie wymaga kończenia studiów filozoficznych do swojego zastosowania.
Moim zdaniem, to czego zabrakło naszym dwóm filozofom to narzucenie problemowi testowania pewnych ram praktycznych. Każdy proces tworzenia oprogramowania jest bowiem ograniczony w przynajmniej dwóch wymiarach: czasu i kosztów. I choć serce oraz wrodzona nieufność wobec kolegów programistów podpowiada mi, aby podążać jednak ścieżką naznaczoną przez Kartezjusza, doskonale wiem, ile potrafią trwać testy i jak kosztowna i krucha w utrzymaniu może być próba osiągnięcia mitycznego pełnego pokrycia automatami. Doświadczenie uczy, że ważniejsza od ilości testów jest ich jakość oraz dobrze dobrana kolejność. Testów nowego feature’a nie powinniśmy zaczynać od sprawdzenia walidacji maksymalnej ilości znaków na jakimś nieistotnym polu tekstowym albo poprawności użytego regexa testującego format emaila – powinniśmy zacząć od rdzenia i esencji funkcji, którą sprawdzamy. Jak ocenić co jest czym? Każdy tester musi nauczyć się tego samemu, a przyjdzie mu to tym łatwiej, im więcej ma doświadczenia.
Praktyka uczy, że w budowie dobrego zestawu testów, ważna jest pewna systematyczność. Za każdym razem, gdy do systemu dodajemy nowy fragment, powinniśmy rozszerzyć także bibliotekę naszych testów. W ten sposób ich koszt niejako rozmywa się pośród kosztów związanych z wytworzeniem danej funkcji. Ma to ważne znaczenie psychologiczne – z jakiegoś bowiem powodu managerowie bardzo nieprzychylnie patrzą na wszelkie koszty, które wydają im się możliwe do pominięcia. A co z oczu, to z serca – prawda jest bowiem taka, że szanujący się zespół programistów i testerów nigdy – podkreślam to – nigdy nie powinien prosić żadnych biurokratów o zgodę na robienie swojej roboty w sposób fachowy, zgodny ze sztuką. Tak samo jak chirurg nie pyta dyrektora szpitala czy po skończonej operacji może zaszyć pacjenta – taką przynajmniej mam nadzieję. Czy jest jakiś lekarz na sali, który mógłby to potwierdzić? Czułbym się spokojniejszy.
Wracając do pisania testów – nie wiem, jak było w czasach Kartezjusza – ale dzisiaj istnieje co najmniej kilka ich rodzajów. Te największe, najdroższe i najwolniejsze nazywają się end-to-end i polegają na tym, że automat wciela się niejako w testera i symuluje jego ruchy w oknie przeglądarki. Prawda jest jednak taka, że nie wszystko musimy testować właśnie w taki sposób. Bardzo dużą część systemu można przetestować taniej, np. za pomocą testów jednostkowych. Bardziej złożone fragmenty możemy przetestować z pominięciem warstwy graficznej – z wykorzystaniem testów integracyjnych. Święty Tomasz z Akwinu znany był ze swojego praktycznego podejścia – być może, ale nie wiem tego na pewno – dawniej istniały tylko testy e2e, które są wyjątkowo kruche, i często mogą failować bez większego powodu? A skoro mogą failować czasami, to czy możemy im w ogóle ufać? A skoro nie możemy im ufać to czy warto je w ogóle pisać? Czym jest życie? Może to jednak Tomasz miał rację. Nie wiem.
Dla osób, które zdążyły się pogubić w meandrach filozofii testowania prezentuję obiecaną heurystykę. Im dłużej o niej myślę tym bardziej dochodzę do wniosku, że rozwiązania dla większości problemów są zawsze z nami gdzieś blisko – musimy umieć je tylko dostrzec. Tak i w tym przypadku, często śpiewana na polskich weselach piosenka zawiera w sobie tą uniwersalną prawdę, ile powinniśmy testować i kiedy, a oto jej błyskotliwy fragment:
Cztery razy po dwa razy osiem razy raz po raz O północy ze dwa razy i nad ranem jeszcze raz - autor nieznany
* prawdziwa treść cytatu: „Być albo nie być; oto jest pytanie: Czy szlachetniejszym jest znosić świadomie Losu wściekłego pociski i strzały, Czy za broń porwać przeciw morzu zgryzot, Aby odparte znikły?”
** prawdziwa treść cytatu: „For those with faith, no evidence is necessary; for those without it, no evidence will suffice.”
*** prawdziwa treść cytatu: “Należy wierzyć jedynie temu, cośmy doskonale poznali i w co nie można wątpić.”