DevTalk Trio Q&A: Kiedy nie warto pisać testów?

Trochę kontrowersyjne pytanie… ale trzeba odpowiedzieć ;).

Maciej: Ja ogólnie jestem test freakiem, a w tym roku w ogóle robię dziwne rzeczy. Nie dość, że pierwszy raz w życiu jadłem tatara, krewetki, napisałem komentarz w kodzie, kupiłem iPhone’a, to jeszcze napisałem kod bez testów, który działa. I ja żyję, i on działa. Wszystko, co widzicie w aplikacji „Daj się poznać”, przeszło w sumie dwa testy – i śmiga! Tak że odpowiedź na pytanie sprowadza się do tego, jaka to jest aplikacja i do czego służy. Aplikacja, o której mówiłem, została napisana – gdyby podsumować całość prac – w tydzień. Ona będzie sobie żyła przez krótki czas, a potem pójdzie do piachu, ewentualnie zostanie ponownie odpalona przy kolejnej edycji. To jest właśnie coś, co testów nie wymaga, bo to coś banalnego. Ale jak piszę aplikację, która ma mieć dłuższy żywot, to moim zdaniem testy trzeba zawsze przeprowadzić, bo po prostu sprawiają, że kod będzie lepszy.

Sławek: Ja bym się nie zgodził z tym, że będzie lepszy…

Maciej: Mam na myśli pisanie testów przed napisaniem kodu. Niekoniecznie musi to być test-driven development, niech będzie test first approach, jak ja to nazywam, czyli test przed napisaniem kodu, choćby to było 20 testów naraz, nie musi być wcale jeden. To sprawi, że kod będzie lepszy.

Sławek: Nadal uważam, że to zależy od osoby. Kod jest dobry, kiedy masz pewien skill, potrafisz projektować kod, czyli znasz wzorce, paradygmaty, techniki, zasady itd. Jestem w stanie wyobrazić sobie człowieka, który nie ma pojęcia o designie kodu, napisze bardzo dużo testów i dalej ten kod będzie słaby. Więc moim zdaniem, pisząc testy, wciąż można mieć słaby kod. Ale już oczywiście pisanie testów z wiedzą na temat pewnych pryncypiów projektowania sprawi, że rzeczywiście kod będzie bardzo dobry. Mówi się, że test ma nas zmusić do ładnego kodu. Nie, nie musi tak być. Bo złe testy i syfiasty kod – to nadal nic nie daje.

Maciej: Ale ja oczywiście mam na myśli dobre testy. Moją misją jest nauka ludzi, jak napisać testy. Bo rzeczywiście jak się napisze złe testy, to one nic nie dadzą.

Powiedziałem: misja! I wcielam ją w życie!
W październiku robię szkoleniowe tournee po Polsce.
“Testowanie automatyczne w praktyce“. Warszawa, Kraków i Wrocław.
Daty, szczegóły i rejestrację znajdziesz tutaj. Zapraszam!

Sławek: Jeżeli dobrze wiem, co chcę zrobić, np. robię sobie TDD, mam dobrze poznaną domenę, wiem, jak ma działać agregat, wiem, jak go wyspecyfikować, to mogę najpierw napisać testy. Ale jeżeli piszę framework – a czasem piszę, bo lubię, raz na rok trzeba sobie napisać malutki framework – i dzisiaj piszę kodzik, a jutro budzę się i wszystko rozwalam, bo mam zupełnie inną koncepcję, inny kształt, bo sobie wyobrażam bardzo przestrzennie cały kod, tworzę jakby z gliny i postanawiam lepić zupełnie od innej strony, to test mi tylko przeszkadza. Więc zależy, kto pisze, co pisze, jak rozumie dany problem, czy jest w fazie kreacji, czy w fazie implementacji. Tak że moim zdaniem odpowiedź brzmi: to zależy.

Maciej: Ktoś napisał: „Kod dobry a kod testowalny to dwie różne rzeczy”. Akurat moim zdaniem kod testowalny równa się kod utrzymywalny…

Andrzej: Ja trzymam się jednak zasady, żeby pisać test przed implementacją – choć oczywiście są wyjątki od tej zasady, spotkałem się z takimi w trakcie swojej kariery. Ale na co dzień kieruję się właśnie tą zasadą i jak mam problem do zaimplementowania, to się zastanawiam: OK, chcę napisać testy, to jest mój start. Czy jestem gotowy? Nie. Może potrzebuję zrobić spike’a, jakiś kodzik, który jest do wywalenia, lub upewnię się, czy design, o którym myślę, ma sens, czy to się trzyma kupy. Napiszę, wywalę, staram się mieć dyscyplinę. I po tym są TDD – wtedy piszę test, kodzik, test, kodzik. To też są fajne techniki. Uncle Bob miał fajny zestaw technik, mówił nawet, w jakiej kolejności pisać testy, żeby nie utknąć na jakimś kroku, żeby nie robić zbyt dużych przeskoków na testach. To był fajny, zdyscyplinowany sposób. Więc to jest dla mnie punkt wyjścia, od tego bym zaczynał. Wiadomo, zdarza się, że utknę, nie ma co przesiadywać wiele godzin nad sytuacją, w której nie wiadomo, jak ruszyć z testami, napiszę kod bez nich, trudno, przeżyjemy, ktoś ten dług kiedyś spłaci. Bo to jest dług, ale staram się naprawdę rzadko go zaciągać.

Maciej: Mam prezentację o testowaniu wyciągniętą z mojego szkolenia na temat testów – o testowaniu w scenariuszach wielowątkowych – i kiedyś spędziłem siedem godzin, pisząc jeden test, który udowadnia, że jest błąd w kodzie wielowątkowym. Gdybym tego nie zrobił, gdybym nie napisał testu przed poprawieniem buga, to bym nie wiedział, czy błąd tam był. Po drugie nie miałbym dowodu na to, że błąd został poprawiony.

Sławek: Ale jak wy testujecie wątki na Windowsie, skoro menedżer wątków w Windowsie jest deterministyczny? W jednym z podcastów opowiadaliśmy historię Roda Johnsona, twórcy Spring Framework w Javie, o tym, jak sam złapał się na tym, że był ćpunem testowym, był uzależniony od zielonego paska, i jak jego żona była zła – ale tego musicie sami posłuchać.

Maciej: Ważne jest też to, co powiedział Andrzej: że jak zaczyna się pisać bez testów, to trzeba zdawać sobie sprawę z tego, że kod może być do wyrzucenia. Moim zdaniem bardzo często jest tak, że robimy jakiegoś spike’a, jakiś prototyp, a potem co się dzieje? Ląduje na produkcji, obrasta w kolejne warstwy ohydnego tłuszczu. Tu skopiuję, tu wpasuję, coś tu zamieszam, skompiluję i śmiga. No właśnie nie!