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

5

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


To jedno z kilkudziesięciu pytań zadanych podczas sesji DevTalk Trio Live Q&A.


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!


Całość rozmowy w formie video do obejrzenia na YouTube, zapraszam!

Share.

About Author

Programista, trener, prelegent, pasjonat, blogger. Autor podcasta programistycznego: DevTalk.pl. Jeden z liderów Białostockiej Grupy .NET i współorganizator konferencji Programistok. Od 2008 Microsoft MVP w kategorii .NET. Więcej informacji znajdziesz na stronie O autorze. Napisz do mnie ze strony Kontakt. Dodatkowo: Twitter, Facebook, YouTube.

5 Comments

  1. Podoba mi się stwierdzenie “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.”

    No właśnie, jak można pisać test nie znając dobrze np.:
    a) języka programowania i jego zawiłości
    b) działania wykorzystywanych bibliotek
    c) architektury przyjętej w istniejącym kodzie/aplikacji
    d) wzorców projektowych
    e) nie mając doświadczenia w postaci źle prowadzonych projektów aby docenić wartość wynikającą z pisania testów, które ochronią Cię w przyszłości przez uszkodzeniem aplikacji ?

    W zupełności zgadzam się ze Sławkiem.

    • Argumenty często spotykane i oczywiście mają swoje racje, ale… jak nauczysz się pisać testy bez pisania testów? Właśnie testy pomagają to wszystko odkrywać, bo są często prostsze niż kod testowany. Można dopisać/usunąć własne testy i badać jak się kod zachowuje.

  2. No to jest właśnie takie błędne koło. Aby tworzyć dobry kod i dobre testy trzeba zacząć od słabego kodu i słabych testów i w miarę dochodzenia do wprawy usprawniać różne techniki.

  3. Maciej poruszył najważniejszy wątek: jeśli aplikacja jest planowana na dość długi cykl życia, z długim rozwojem, testy są obowiązkowe, inaczej po pewnym czasie zaczną wychodzić dziwne regresje. Jeśli chcesz ograniczyć liczbę testów, trzeba dobrze je rozplanować, co testem pokryć, a czego nie…

    Co do stricte TDD… co kto lubi :P moim zdaniem łatwo może zaprowadzić do złego kodu, który często będzie wymagał refaktoryzacji, przy każdej próbie rozszerzenia.

  4. Rozpisałem się jak głupi, uzupełniłem tylko pole “name” po czym przekierowało mnie na stronę z informacją o uzupełnienie emaila i website’u. Wróciłem na tą podstronę i oczywiście cała zawartość komentarza poszła w gwizdek. Cóż za UX ! Stracił Pan przynajmniej jednego potencjalnego kupca ;-)