Testy podobnie jak kod produkcyjny ewoluują. Zmieniają się w czasie. Czasem to dobra zmiana, a czasem niekoniecznie. Wtedy nabierają złego zapachu. Phoebe z Friends’ów śpiewała kiedyś Smelly Cat, Smelly Cat, it’s not your fault, równie dobrze mogłaby zaśpiewać Smelly Test, Smelly Test, it’s not your fault. To nie wina testu, iż coś się z nim dzieje, tylko ignorancji zespołu projektowego, który przechodzi obojętnie udając, iż wszystko jest ok. Postanowiłam wziąć na warsztat testy, które nie pachną dobrze, żeby pokazać jak małymi krokami można dojść do całkiem niezłych efektów.
Weźmy na przykład taki test:
@Test void shouldReturnOne() { int result = calculator.add("2"); assertThat(result).isEqualTo(2); }Czy jest krótki? Tak! Czy testuje jedną rzecz? Owszem. Czy czytelną asercję? No ma! Coś jednak tam nie gra…
Tym czymś jest nazwa. Po pierwsze ta nazwa kilka mówi. Wiadomo, iż Object Under Test, czyli w tym przypadku jakiś StringCalculator ma zwrócić 1. Ale czego to jest wynik? Dlaczego oczekujemy akurat takiego wyniku? Nie wiadomo. To nie koniec nieścisłości.
Drugim problemem jest fakt, iż zmienił się przykład. Prosta zmiana z 1 na 2, albo raczej “1” na “2”. Czy nazwa metody testowej za tym podążyła? No nie bardzo. Czy powinniśmy zmienić nazwę na shouldReturnTwo? Moim zdaniem kilka to zmieni, bo za chwilę zapragniemy przetestować przypadek “3”.
Jak nie nazywać testów?
Opieranie nazw testów na przykładzie to średni pomysł. Jasne, iż można od tego zacząć. Należy zaczynać gdziekolwiek zamiast godzinami myśleć nad doskonałym kodem. Ale potem dobrze jest zrobić audyt. Spojrzeć krytycznym okiem na nasz test i zastanowić się, czy ta nazwa w raporcie będzie jednoznaczna i czy będzie odzwierciedlać prawdziwe działanie systemu. Jaką nazwę nadać temu nieszczęsnemu testowi?
Można nazwać go chociażby shouldReturnNumberWhenSingleNumberGiven. To się tak naprawdę tutaj dzieje. Kiedy kalkulator dostanie pojedynczą liczbę w formie tekstu to po prostu zwróci ją jako liczbę całkowitą. Mój kalkulator pozwala jedynie na dodawanie liczb. Gdyby doszło do tego mnożenie czy dzielenie, wtedy należałoby uzupełnić okoliczności w nazwie testu. Wszystko po to, żeby było jasne której funkcjonalności dotyczy test. No bo jeżeli przestałby przechodzić, powinno być jednoznaczne co się zepsuło, bez konieczności otwierania klasy testowej.
Test białej rękawiczki
Warto raz na jakiś czas zaglądać do testów i robić im audyt. Zwłaszcza przy okazji zmian dokonywanych w kodzie. Taka reguła skauta dla testów. Czy czytając testy wiesz co one robią? Czy rozumiesz na czym się opierają? Czy czasem nie opierają się na implementacji zamiast wymaganiach biznesowych?
Takie i inne problemy z testami omawiam w serii Pimp My Tests. Pierwsze odcinki jest już dostępne na moim kanale na YouTube. Daj znać, jeżeli uda Ci się przeprowadzić test białej rękawiczki w swoim kodzie testowym!
