Podsumowanie szkolenia z Test-driven development



Dima Boyko (Software Engineer, inFakt.pl): Cześć! Nazywam się Dima i dzisiaj cały dzień spędzamy na szkoleniu z Test – driven development (TDD). Mam nadzieję, że poznam dużo więcej teorii na temat TDD i sposobów jak to zastosować w praktyce.

Cześć! Jesteśmy dzisiaj poza biurem cały dzień na takim szkoleniu z TDD. Powiedz proszę co to za szkolenie? Dlaczego tam jesteśmy? I skąd w ogóle pojawił się pomysł takiego szkolenia?

Sebastian Bobrowski (CTO inFakt.pl): Wiesz, w aplikacji takiej jak inFakt testy są jakby bardzo ważnym elementem bo pracujemy na danych księgowych klientów i to, żeby się liczył PIT, VAT poprawnie, żeby generowały się poprawnie deklaracje i rejestry jest super ważne, no i żeby to dobrze działało to z jednym z elementów są testy. Wszyscy te testy piszą, jakby każdy kto przychodzi jakieś tam ma podstawy samego pisania testów.

O TDD natomiast, każdy tak wiesz słyszał, ale często tylko słyszał, a wiesz, mało kto to stosuje w praktyce. I sam się chciałem też bardzo mocno tego nauczyć i stąd idea tego, że zróbmy takie szkolenie, taki wstęp do TDD, tak żeby zrozumieć z jednej strony filozofię i z drugiej strony coś spróbować się tak nauczyć realnie.

Dima: A powiedz proszę jak wygląda proces nauki TDD na takim szkoleniu? Opowiedz co robiliśmy i jakie to ma efekty.

Sebastian: No ten proces nauki TDD był bardzo powiązany z techniką, która mi się podoba, czyli pair programming. W takim kontekście, że w TDD są takie trzy, jakby każdy cykl składa się z trzech elementów: red – green – refaktor. W red najpierw piszemy test, który z definicji ma nie przechodzić, później sprawiam żeby był zielony, czyli piszemy kod produkcyjny który wykonuję, także ten test przechodzi, a na końcu jest refaktor. Tutaj Pair Programming bardzo mocno się sprawdza, ponieważ na te trzy cykle można się zamieniać klawiaturą.

Mieliśmy takie ćwiczenie w parach, gdzie dwie osoby pracowały przy jednym laptopie i na przykład: ty najpierw pisałeś test, który nie przechodzi, następnie ja robiłem implementację produkcyjną i klawiatura wracała do ciebie po to, żeby zrobić refaktor tego co ja wcześniej zrobiłem. No i to wydaję mi się, że jest całkiem niezła technika, jak tego się nauczyć nawet gdy później nie piszę się, nie stosuję się TDD w codziennej pracy łącznie z pair programming. To samemu można takie robić sobie w głowie trzy cykle, że jest red – green – refaktor. To wydaję mi się, że jest niezła technika do tego, żeby się nauczyć. Ja dużo zrozumiałem, więcej niż wiedziałem wcześniej.

Dima: Właśnie wiem, że bardzo często stosujemy pair programming i właśnie siedzimy przy jednej maszynie. Uważasz, że przy produkcyjnym pisaniu testów do aplikacji produkcyjnej warto stosować taki sam tryb jak robiliśmy na szkoleniu, że siedzimy we dwóch i piszemy te testy? Czy bardziej pair programming osobno, a takie TDD w takie tryby przełączać samemu dla siebie?

Sebastian: Wydaję mi się, że warto spróbować, nigdy wcześniej tego nie robiłem tak produkcyjnie. Ta klawiatura na pewno tak dynamicznie wtedy się rusza pomiędzy osobami, ale no w tym przykładzie, który robiliśmy było stosunkowo łatwe zadanie, więc ona jak gdyby dużo „biegała”. Pewnie w takim naszym jakimś produkcyjnym zadaniu, no to jakby ten czas na napisanie dobrych testów i nad nimi się zastanawianie jest większy. Później czas na napisanie kodu i na refaktoryzację jest większy, więc pewnie nie jest to tak dynamicznie. Wydaję mi się, że można to co najmniej przetestować.

Dima: Ok, a jak oceniasz to szkolenie pod względem takiej wiedzy? Czy dużo się nauczyłeś? Czy większość tego już wiedziałeś i teraz to była po prostu okazja, żeby to sobie przypomnieć albo poćwiczyć albo po prostu większość z technik TDD dowiedziałeś się tutaj?

Sebastian: Jakby wiedziałem, znałem takie podstawy teoretyczne, nigdy nie miałem tej wiedzy takiej ugruntowanej i nigdy tego nie miałem takiego jakby wiesz opowiedzianego w praktyce. No i tu mieliśmy Krzyśka, który nas szkolił, który 95% swojego czasu pracy, pracuje w ramach TDD, więc ma z tym na pewno duże doświadczenie, no i od niego jakby dużo zrozumiałem tego w jaki sposób można to tak w praktyce stosować. Także wiesz, coś wiemy teoretycznie, ale do praktyki czasem jest kawałek, no i mnie to bardzo mocno przybliżyło. Nie dowiedziałem się nic takiego super odkrywczego, ale te rzeczy, które były, były takimi bardzo dobrymi podstawami do tego, żeby zacząć to stosować na co dzień, by móc iść dalej w tym kontekście.

Dima: Czyli wyniosłeś trochę wiedzy z tego szkolenia?

Sebastian: Wyniosłem wiedzę. Wyniosłem takich wiesz wiele tipów jak to zrobić. Na przykład o tym, że można na kolejne te etapy przerzucić tę klawiaturę, na kolejne etapy od jednego developera do drugiego. Nie wiedziałem, że to tak można zrobić.

Dima: Ok, a pamiętasz na przykład czym się różni w testach, w aplikacjach Rails i ogólnie w testowaniu Fake, Stub i Mock na przykład?

Sebastian: Wiedziałem to wcześniej, ale nigdy tego tak dobrze nie umiałem opowiedzieć. I teraz już wiem, że Mock musi zostać wywołany i tutaj jakby badamy, czy dana metoda na przykład innej klasy została wywołana, natomiast Stub bardziej zwraca nam wartość. Jeżeli chcemy mieć jakąś wartość, to wtedy stub-ujemy, natomiast jeżeli chcemy zbadać czy inna metoda w innej klasie została wywołana, to wtedy to mock-ujemy.

Dima: Ok, a tak jeszcze podsumowując szkolenie, jakbyś nazwał trzy punkty, o których warto pamiętać przy napisaniu testów? Trzy punkty super ważne przy napisaniu testów? Jakie powinny być te testy?

Sebastian: Te testy na pewno powinny być takie wyizolowane, testy poprawiają nam architekturę. Bardzo mocno o tym nam Krzysiek jako szkoleniowiec opowiadał, że testy poprawiają nam architekturę, ponieważ najpierw jakby się zastanawiamy nad architekturą. To jest tak, że klasę w Ruby, czy w dowolnym języku to każdy jest w stanie napisać.

Natomiast dobra architektura wymaga już trochę więcej jakby myślenia i więcej zrozumienia, więc dobre testy są dla mnie takie, które powodują, że architektura jest dużo lepsza, też szybko działają. No bo to jest też bardzo ważny element, szczególnie w dużej aplikacji testy muszą się nam szybko uruchamiać i szybko się wykonywać, po to, żebyśmy informację o tym, że test przechodzi lub szczególnie nie przechodzi, mieli szybko. To myślę, że takie najważniejsze punkty.

Dima: To podsumowując, uważasz że było warto poświęcić dzień pracy developerów na takie szkolenie? Jakie są korzyści w ogóle z TDD w biznesie w praktyce?

Sebastian: Wydaję mi się, że warto. Dla mnie bardzo ważnym elementem jest to, żeby osoby które mamy dzisiaj w zespole były coraz lepszymi developerami i jednym z elementów tego jest TDD. Moja wizja jest też taka, że wiesz jako zespół techniczny, zespół IT, zespół developerów nie chcemy się tak bardzo mocno rozrastać.

Chcemy, żeby były nowe osoby, ale nie chciałbym żeby było to tak bardzo mocno, a żeby realizować potrzeby biznesowe możemy to zrobić w ten sposób, że właśnie się szkolimy, po to żeby praca każdej osoby była dużo bardziej efektywna, aby „jeździć z taczkami dużo bardziej zapakowanymi niż z pustymi”. Według mnie warto poświęcić jeden dzień, co najmniej jeden dzień i też kolejne dni żeby praca każdej osoby była dużo bardziej efektywna i przynosiła dużo więcej radości.

Dima: A tak konkretnie z tego szkolenia, jakie są korzyści takiego TDD i zastosowania TDD u nas?

Sebastian: No to na pewno lepsza architektura. To jest taki dla mnie główny element, po to żeby coś łatwo było przetestować musi to być łatwo implementowalne i wtedy, jeżeli się nad tym zastanawiamy w momencie przed implementacją, no to dużo łatwiej podzielić sobie to na moduły i klasy. Drugim ważnym elementem jest taka pewność tego, że wypuszczamy dzisiaj kod na produkcję i że on działa. Został przetestowany, wiadomo że został przetestowany częściowo ręcznie, najpierw zobaczył to pierwszy developer, drugi, potem tester, zwykle jeszcze Product Owner zobaczył czy ten kod faktycznie działa, ale no nie zawsze przetestujemy wszystkie elementy.

Natomiast TDD daję nam to, że jesteśmy w stanie mieć cały czas wszystkie przypadki przetestowane. Dzięki temu mamy później mniej błędów, mamy mnie debugowania, no i mniej czasu spędzamy nad tym, żeby się wracać, na tym utrzymaniu kodu, więc dla mnie to jest super technika i w inFakcie ona ma bardzo duże jakby znaczenie, ponieważ cały czas dobudowujemy do istniejącego produktu. W sytuacji, gdybyśmy mieli aplikację, którą robimy i za chwile ją przestajemy robić to pewnie mniej, natomiast my cały czas dobudowujemy do głównego produktu i dlatego bardzo ważne jest, żeby nie mieć tej takiej regresji wstecznej, czyli żeby nie mieć sytuacji, że z powodu tego, że mamy dzisiaj nową funkcjonalność jakaś tam inna, trzy funkcjonalności temu coś nam przestaję działać. No i tu TDD jest dla mnie jedynym możliwym rozwiązaniem.

Dima: Super, czyli idziemy teraz kontynuować tę szkolenie!

Sebastian: Tak jest.