Blog

Wiadomo, że Test – Driven Development to najpopularniejsze obecnie podejście do pisania kodu wysokiej jakości, stosowane między innymi przez Google, Microsoft, Apple. Wydaje się, że TDD to świetne narzędzie, dlaczego zatem tak mało osób stosuje tę metodykę?

Powodów może być kilka. Jednym z nich z pewnością jest fakt, że zdecydowana większość obecnych systemów informatycznych została napisana w sposób uniemożliwiający łatwe testowanie, refaktoryzację czy choćby ciągłą integrację. Stąd zastosowanie TDD out-of-the-box jest prawdziwym wyzwaniem o ile nie posiada się odpowiedniej wiedzy i praktyki. Z tego względu ponad połowa warsztatów jest poświęcona testom charakteryzacyjnym, automatycznej refaktoryzacji (przy wsparciu IDE) czy pracy z legacy code.

Innym powodem może być niska świadomość wartości, jakie niesie ze sobą poprawnie zbudowana piramida testów, której podstawę stanowią testy jednostkowe. Kolejnym niech będzie tak prozaiczna przyczyna jak fakt, że samodzielna nauka TDD bywa trudna (jeśli nie ma w pobliżu kogoś kto byłby w stanie udzielić cennych wskazówek i naprowadzić na poprawny tok myślenia w chwilach zwątpienia).

Ale po kolei- czym jest Test-Driven Development i jakie korzyści dla uczestników niesie warsztatowa forma szkolenia?

Przede wszystkim szkolenie TDD składa się z czterech logicznych modułów, które w zależności od potrzeb mogą być omawianie bardzo dokładnie lub jedynie pobieżnie – mechanika TDD, clean code, refactoring, praca z legacy code; oczywiście wszystko w duchu Test-Driven Development. Dobór modułów nie jest przypadkowy, a stanowi on wypdkową wieloletniej pracy zawodowej oraz współpracy kilku doświadczonych trenerów Code Sprinters.

Warto podkreślić, że w trakcie zajęć skupiamy się głównie na doskonaleniu umiejętności praktycznych oraz budowaniu tzn. mindsetu, by osoby po warsztatach nie tylko potrafiły ślepo wykonywać zestaw instrukcji, ale również rozumiały, dlaczego warto.

Tematyka szkolenia koncentruje się wokół architektury kodu. Do kogo skierowane jest szkolenie? Czy powinni brać w nim udział programiści czy raczej testerzy?

Z racji tego, że Test-Driven Development jest techniką mającą na celu projektowanie aplikacji poprzez wymagania czy nawet przypadki użycia zapisane w postaci testów, idealnymi kandydatami są osoby na co dzień pracujące z kodem. W znacznej większości przypadków będą to właśnie programiści . Może się natomiast zdarzyć tak, że testerzy, którzy większość czasu spędzają na przygotowaniu testów automatycznych zyskają bardzo wiele dzięki modułom, takim jak clean code, code refactoring czy legacy code.

Tak naprawdę, realnym wymaganiem jest jedynie chęć nauki i obycie z kodem.

Czy szkolenie pozwoli uczestnikom na tyle zapoznać się ze wszystkimi aspektami wytwarzania oprogramowania w podejściu Test-Driven Development, aby móc samodzielnie stosować Test-Driven Development w swojej pracy?

Jak najbardziej! W trakcie przeszło dwóch lat prowadzenia warsztatów TDD były one nieustannie modyfikowane, na bazie zarówno własnych obserwacji, jak i sugestii uczestników, po to by materiał w nim zawarty w pełni przygotowywał uczestnika do świadomego stosowania sprawdzonych praktyk TDD, clean code czy pracy z legacy code. Naturalnie nie wszystko można osiągnąć w ciągu dwudniowych zajęć, dlatego na koniec uczestnicy otrzymują zestaw wskazówek oraz zadań pozwalających na dalsze pogłębianie wiedzy i doskonalenie umiejętności praktycznych.

Częstym pytaniem naszych klientów jest to, czy można zamiast przykładów i ćwiczeń pracować w czasie szkolenia nad kodem klienta?

Warsztaty są skonstruowane tak by drugiego dnia w zależności od potrzeb przeznaczyć od dwóch do czterech godzin na pracę z przykładami przedstawionymi przez uczestników. W tym czasie dokonujemy nie tylko suchej analizy kodu, ale również jego modyfikacji / refaktoringu, o ile taka jest wola grupy.

Nie mam nic przeciwko o ile tylko kod dostarczony przez klienta zawiera elementy istotne z punktu widzenia szkolenia takie jak elementy legacy code, czy naruszenie zasad SOLID, clean code.

Podobno największym plusem TDD jest możliwość stosowania jej zarówno przez pojedynczych developerów, jak i przez całe zespoły. Jakie jeszcze zalety tej metodologii możesz wymienić? I czy są w niej jakieś wady?

Tak, to prawda. TDD przynosi wartość, nawet jeśli jest stosowane przez pojedynczego developera. Na szczęście jest zaraźliwe, w końcu każdy z nas chce pisać lepszy kod.

Jeśli chodzi o wady, zawsze powtarzam, że pierwsze tygodnie pracy z TDD mogą skutkować niewielkim spadkiem wydajności i jest to zupełnie normalne. Dzieje się tak, dlatego że programista, który musi całkowicie zmienić swoje podejście do wytwarzania oprogramowania nigdy z początku nie będzie tak produktywny, jak ktoś powtarzający ten sam schemat od lat.

A co, jeśli nie korzystamy z technik zwinnych- to znaczy, że nie musimy korzystać z TDD?

Całe piękno TDD polega na tym, że można go stosować bez względu na rodzaj projektu, czy metodologię w jakiej jest prowadzony nic przy tym nie tracą. Dzieje się tak dlatego, że w TDD skupiamy się głównie na dostarczeniu kodu wysokiej jakości w pełni pokrytego testami abstrahując od całej otoczki, co z pewnością przyda się w każdym projekcie o dużych aspiracjach.

Program szkolenia podzielony jest na trzy zasadnicze części: Test-Driven Development, Pisanie testów i testowalnego kodu oraz Refaktoryzacja i jakość kodu.Czy pośród wielu zagadnień poruszana jest również tematyka statycznej analizy kodu?

Ze względu na ramy czasowe tematyka statycznej analizy kodu jest najczęściej poruszana w momencie prezentacji zagadnień clean code, nie stanowi ona jednak fundamentów szkolenia także nie poświęcamy jej dużej porcji czasu.

Czy podejście TDD do procesu tworzenia oprogramowania uwzględnia zmiany w wymaganiach produktu już po rozpoczęciu pisania kodu?

Elementem, który pozwala- w pewnym stopniu- zmieniać wymagania już po rozpoczęciu pracy nad funkcjonalnością jest kod wysokiej jakości, czysty, dobrze zaprojektowany i przetestowany. TDD jest jedynie techniką pozwalającą taki kod wytworzyć i to właśnie na niej skupiamy się w trakcie warsztatów.