Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00000 003809 19001233 na godz. na dobę w sumie
TDD. Techniki programowania sterowanego testami - książka
TDD. Techniki programowania sterowanego testami - książka
Autor: Liczba stron: 328
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-283-3531-8 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> programowanie >> techniki programowania
Porównaj ceny (książka, ebook (-35%), audiobook).

Odnieś sukces dzięki TDD!

Metoda Test-Driven Development pozwala na pisanie lepszej jakości, bardziej elastycznego i łatwiejszego w utrzymaniu kodu, na którym można w pełni polegać. Większa wydajność pracy programistów, którzy o wiele lepiej rozumieją potrzeby biznesowe stawiane tworzonym przez nich aplikacjom, znaczne przyspieszenie powtarzalnych testów - to tylko niektóre zalety TDD. Nic dziwnego, że świat zachwycił się tą techniką, a jej znajomość należy do podstawowych wymagań, które muszą spełnić inżynierowie pragnący rozwijać swoją karierę w branży IT.

Jeśli chcesz poznać metodę TDD i nauczyć się tworzyć zgodne z nią testy jednostkowe, trafiłeś na właściwą książkę! W prosty sposób przedstawi Ci ona cykl Red-Green-Refactor, zaprezentuje zalety poprawnie zaimplementowanej techniki TDD, zwróci uwagę na trudności związane z wdrażaniem tej techniki i podpowie, jak sobie z nimi poradzić. Nauczysz się z niej pisać testy jednostkowe zgodnie z dobrymi praktykami oraz sprawdzać zależności i tworzyć atrapy obiektów. Dowiesz się, jak stosować TDD w przypadku już istniejącego kodu, a także jak mierzyć pokrycie kodu testami. Poznasz również podstawowe informacje na temat ciągłej integracji i jej znaczenia dla techniki TDD.

Poznaj w praktyce najbardziej przebojową metodę tworzenia oprogramowania!

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną, fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym powoduje naruszenie praw autorskich niniejszej publikacji. Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi ich właścicieli. Autor oraz Wydawnictwo HELION dołożyli wszelkich starań, by zawarte w tej książce informacje były kompletne i rzetelne. Nie biorą jednak żadnej odpowiedzialności ani za ich wykorzystanie, ani za związane z tym ewentualne naruszenie praw patentowych lub autorskich. Autor oraz Wydawnictwo HELION nie ponoszą również żadnej odpowiedzialności za ewentualne szkody wynikłe z wykorzystania informacji zawartych w książce. Redaktor prowadzący: Małgorzata Kulik Projekt okładki: Studio Gravite / Olsztyn Obarek, Pokoński, Pazdrijowski, Zaprucki Grafika na okładce została wykorzystana za zgodą Shutterstock.com Wydawnictwo HELION ul. Kościuszki 1c, 44-100 GLIWICE tel. 32 231 22 19, 32 230 98 63 e-mail: helion@helion.pl WWW: http://helion.pl (księgarnia internetowa, katalog książek) Drogi Czytelniku! Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres http://helion.pl/user/opinie/tddppr Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję. Kody źródłowe wybranych przykładów dostępne są pod adresem: ftp://ftp.helion.pl/przyklady/tddppr.zip ISBN: 978-83-283-3531-8 Copyright © Helion 2018 Printed in Poland. • Kup książkę • Poleć książkę • Oceń książkę • Księgarnia internetowa • Lubię to! » Nasza społeczność Spis treści Podziękowania ................................................................................................. 11 Przedmowa ...................................................................................................... 13 Cytaty o TDD ..................................................................................................... 15 Wstęp .............................................................................................................. 17 Przewodnik po książce ............................................................................................................ 19 Dla kogo jest ta książka? ......................................................................................................... 20 W jakim stopniu muszę umieć programować? ............................................................ 20 Nie jestem programistą C#. Czy ta książka ma jakąś wartość dla mnie? .................. 20 Umiem pisać testy jednostkowe i znam TDD. Czy ta książka jest dla mnie? .......... 21 Jestem menadżerem/dyrektorem/właścicielem (a więc nie programuję), a mój zespół chce wdrożyć TDD. Czy z tej książki dowiem się, czy warto? ......... 22 Jestem manualnym testerem. Czy powinienem znać TDD? ...................................... 22 Kontekst jest królem ................................................................................................................ 23 Atrapa to mock czy test double? .................................................................................... 23 xUnit a xUnit.net .............................................................................................................. 24 Funkcja a funkcjonalność oraz funkcyjny a funkcjonalny ......................................... 24 Synonimy ........................................................................................................................... 25 Jak uczyć się metody Test-Driven Development? ............................................................... 25 Dogmat ...................................................................................................................................... 26 Narzędzia użyte w tej książce ................................................................................................. 27 Kod źródłowy do książki ........................................................................................................ 28 Rozdział 1. Wprowadzenie do TDD ...................................................................... 29 Błędy w oprogramowaniu ...................................................................................................... 31 Cykl Red-Green-Refactor ....................................................................................................... 32 Podsumowanie ......................................................................................................................... 33 Poleć książkęKup książkę 4 TDD. Techniki programowania sterowanego testami Rozdział 2. Co zyskujemy dzięki TDD? ................................................................. 35 Wysoka jakość kodu ................................................................................................................ 35 Czy pisanie w metodyce TDD oznacza pisanie według zasad SOLID? .................... 36 Prostota kodu: YAGNI i KISS ................................................................................................ 37 Żywa dokumentacja ................................................................................................................ 38 Lepsze zrozumienie wymagań biznesowych ........................................................................ 38 Automatyczna regresja ........................................................................................................... 39 Informacja zwrotna ................................................................................................................. 41 Mniej defektów ........................................................................................................................ 42 Czas programowania jest krótszy .......................................................................................... 43 Niższy koszt zmian .................................................................................................................. 43 Przypadki użycia ...................................................................................................................... 45 Badanie Microsoft Research nad zespołami Microsoftu i IBM ................................. 45 Pilotażowy projekt dla dużej firmy ................................................................................ 45 Mały projekt w parach ..................................................................................................... 47 Metaanaliza ....................................................................................................................... 47 Podsumowanie ......................................................................................................................... 48 Rozdział 3. Trudności przy wdrażaniu TDD ........................................................... 49 Ścieżka nauki ............................................................................................................................ 49 Dyscyplina ................................................................................................................................ 50 Więcej narzędzi ........................................................................................................................ 50 Początkowa percepcja dłuższego czasu potrzebnego do napisania kodu ........................ 51 Jak „sprzedać” TDD kierownictwu? ..................................................................................... 51 Musimy dostarczać szybko, a w naszym projekcie nie ma czasu na TDD ...................... 51 Lista kontrolna: Definition of Done .............................................................................. 52 Podsumowanie ......................................................................................................................... 56 Rozdział 4. Filozofia TDD ................................................................................... 57 Test-First czy Test-Last? ......................................................................................................... 58 Wszystkie testy naraz czy test po teście? .............................................................................. 59 Weryfikacja stanu czy zachowania? ...................................................................................... 60 Jedna czy wiele asercji? ........................................................................................................... 60 Scenariusz 1.: Jedna oczekiwana zmienna wyjściowa ................................................. 60 Scenariusz 2.: Wiele oczekiwanych zmiennych wyjściowych .................................... 61 Scenariusz 3.: Asercje pośrednie .................................................................................... 62 Wiele asercji w jednym teście ......................................................................................... 66 Kiedy pisanie testów jednostkowych nie ma sensu? ........................................................... 67 Czy należy pisać testy jednostkowe do bibliotek innych dostawców? ............................. 68 Poleć książkęKup książkę Spis treści 5 Czy TDD sprawdza się dla małych aplikacji? ...................................................................... 69 Czy TDD sprawdza się dla dużych aplikacji? ...................................................................... 70 Czy testy jednostkowe zastępują testera? ............................................................................. 70 Jak pisanie testów jednostkowych wpływa na estymatę zadania? ..................................... 71 Czy testy jednostkowe można pisać w innym języku programowania niż pisany jest kod? ................................................................................. 71 Czy testy jednostkowe może pisać inna osoba? ................................................................... 72 Czy system może mieć zbyt dużo testów jednostkowych? ................................................ 72 Czy testy jednostkowe to jedyne testy, jakie powinny znajdować się w aplikacji? ......... 73 Jakich testów powinno być najwięcej (piramida testów)? ................................................. 74 Podsumowanie ......................................................................................................................... 75 Rozdział 5. Rodzaje testów ................................................................................ 77 Sposób wykonywania .............................................................................................................. 77 Wiedza na temat struktury systemu (test skrzynki) ........................................................... 77 Poziom testowania ................................................................................................................... 78 Testowanie po zmianach dokonanych w systemie ............................................................. 80 Testowanie niefunkcjonalne .................................................................................................. 80 Test wydajnościowy ......................................................................................................... 81 Podsumowanie ......................................................................................................................... 82 Rozdział 6. Test jednostkowy ............................................................................. 83 Struktura testu: Arrange-Act-Assert ..................................................................................... 83 Alternatywne struktury testu .......................................................................................... 84 Test jednostkowy a test integracyjny .................................................................................... 85 Myśl jak tester: ścieżki optymistyczne i przypadki brzegowe ............................................ 86 Jak nazywać klasy i metody testowe? .................................................................................... 87 Podział testów i projekty testowe .......................................................................................... 88 Podsumowanie ......................................................................................................................... 89 Rozdział 7. Nasz pierwszy test jednostkowy ........................................................ 91 Wybór biblioteki do testowania ............................................................................................. 91 Zanim zaczniemy… ................................................................................................................ 92 Dodanie solucji i projektów ............................................................................................ 92 Dodanie biblioteki NUnit ............................................................................................... 93 Etap red: pisanie testu do nieistniejącej metody ................................................................. 95 Jak uruchomić test? .......................................................................................................... 98 Etap green: implementacja kodu ......................................................................................... 102 Etap trzeci (i ostatni): refaktoryzacja kodu ........................................................................ 103 Podsumowanie ....................................................................................................................... 103 Poleć książkęKup książkę 6 TDD. Techniki programowania sterowanego testami Rozdział 8. Piszemy kolejne testy jednostkowe .................................................. 105 Drugi test jednostkowy ......................................................................................................... 105 Kolejne przypadki użycia ...................................................................................................... 106 Testy ułamków nieskończonych lub zaokrąglonych ................................................. 108 Testowanie wyrzucenia wyjątku .......................................................................................... 109 Testowanie zdarzenia ............................................................................................................ 111 Podsumowanie ....................................................................................................................... 114 Rozdział 9. Testowanie z NUnitem .................................................................... 115 Asercje ..................................................................................................................................... 116 Model klasyczny i model oparty na twierdzeniach ................................................... 118 Operacja równości ................................................................................................................. 120 Porównanie dwóch typów wartościowych ................................................................. 121 Porównanie dwóch typów referencyjnych ................................................................. 122 Porównanie dwóch typów referencyjnych z nadpisanym operatorem porównania .................................................................. 122 Tolerancja: delta i procent ............................................................................................ 124 Tolerancja: czas ............................................................................................................... 124 Własna klasa obsługująca porównanie ....................................................................... 125 Metody pomocnicze ...................................................................................................... 126 Operacje porównania ............................................................................................................ 126 Własna klasa obsługująca porównanie ....................................................................... 127 Należy do zakresu ........................................................................................................... 128 Złożenia ................................................................................................................................... 128 Testowanie typów .................................................................................................................. 129 Testowanie wyjątków ............................................................................................................ 131 Testowanie, czy kod wyrzucił wyjątek ........................................................................ 133 Testowanie, czy kod nie wyrzucił wyjątku .................................................................. 135 Testowanie parametru i komunikatu wyjątku ........................................................... 136 Testowanie wewnętrznego wyjątku ............................................................................. 137 Typ tekstowy .......................................................................................................................... 137 Kolekcje ................................................................................................................................... 138 System plików ........................................................................................................................ 141 Komunikaty ............................................................................................................................ 142 Własne komunikaty błędów ......................................................................................... 144 Własne komunikaty informacyjne .............................................................................. 145 Komunikat a nazwa testu .............................................................................................. 146 Współdzielenie danych ......................................................................................................... 147 Kiedy korzystać ze współdzielenia danych? ............................................................... 148 Poleć książkęKup książkę Spis treści 7 Testy parametryzowane ........................................................................................................ 150 TestCase ........................................................................................................................... 151 Values ............................................................................................................................... 152 Range ................................................................................................................................ 154 Random ........................................................................................................................... 154 TestCaseSource ............................................................................................................... 155 ValueSource .................................................................................................................... 160 Testy oparte na zewnętrznych źródłach ...................................................................... 160 Strategie łączenia wartości testowych ................................................................................. 161 Test kombinatoryczny ................................................................................................... 161 Test sekwencyjny ............................................................................................................ 162 Test par ............................................................................................................................ 163 Teorie ...................................................................................................................................... 166 Testowanie klas generycznych ............................................................................................. 170 Zasada podstawienia Liskov ......................................................................................... 172 Testowanie wywołań asynchronicznych ............................................................................ 174 Równoległe uruchamianie testów ....................................................................................... 178 Poziom zrównoleglenia ................................................................................................. 179 Kiedy zrównoleglić uruchamianie testów? ................................................................. 179 Pozostałe atrybuty ................................................................................................................. 179 Sterowanie wątkiem ....................................................................................................... 180 Kategoria testu ................................................................................................................ 180 Atrybuty informacyjne .................................................................................................. 182 Przekazywanie parametrów .......................................................................................... 182 Ignorowanie testów ........................................................................................................ 183 Kolejność wykonywania testów ................................................................................... 185 Ustawienia regionalne ................................................................................................... 185 Powtarzanie testu ........................................................................................................... 188 Czas wykonywania testu ............................................................................................... 189 Platforma ......................................................................................................................... 190 Atrybuty a testy parametryzowane .............................................................................. 192 Podsumowanie ....................................................................................................................... 192 Rozdział 10. Testowanie zależności i atrapy obiektów ........................................ 193 Ręczne tworzenie atrapy ....................................................................................................... 195 Kryterium akceptacji nr 1: wiek klienta niższy niż 18 lat ......................................... 196 Kryterium akceptacji nr 2: wiek klienta większy bądź równy 18 lat ....................... 198 Kryterium akceptacji nr 3: jeśli obiekt klienta jest nullem, to wyrzuć wyjątek ..... 200 Podsumowanie ............................................................................................................... 200 Poleć książkęKup książkę 8 TDD. Techniki programowania sterowanego testami Wprowadzenie do frameworku Moq .................................................................................. 201 Składnia imperatywna i deklaratywna ................................................................................ 202 Składnia imperatywna ................................................................................................... 203 Składnia deklaratywna ................................................................................................... 204 Wybór składni ................................................................................................................ 205 Atrapa rekursywna (recursive mock) ................................................................................. 205 Tryb zachowania właściwości (stubbing) ........................................................................... 206 Zwracanie domyślnej wartości ............................................................................................. 207 Atrapa z sekwencyjnym rezultatem .................................................................................... 208 Tryb zachowania atrapy (MockBehavior) .......................................................................... 209 Przekazywanie parametrów w metodzie (argument matchers) ...................................... 210 Ponowne użycie matcherów ......................................................................................... 215 Weryfikacja wywołań ............................................................................................................ 216 Weryfikacja wywołania metody ................................................................................... 217 Weryfikacja dostępu i zapisu właściwości .................................................................. 219 Testować stan czy zachowanie? .................................................................................... 220 Komunikat błędu ........................................................................................................... 221 Podsumowanie ............................................................................................................... 222 Wywołanie zwrotne: Callback ............................................................................................. 222 Podsumowanie ............................................................................................................... 224 Wywołanie składowej bazowej: CallBase ........................................................................... 224 Atrapa wyrzucająca wyjątek ................................................................................................. 226 Inne poziomy dostępności ................................................................................................... 227 protected .......................................................................................................................... 228 internal ............................................................................................................................. 229 Podsumowanie ............................................................................................................... 229 Klasyfikacja atrap ................................................................................................................... 230 Dummy ............................................................................................................................ 230 Stub ................................................................................................................................... 232 Fake .................................................................................................................................. 233 Mock ................................................................................................................................ 235 Spy .................................................................................................................................... 235 Podsumowanie ............................................................................................................... 236 Ograniczenia Moqa ............................................................................................................... 237 Tworzenie atrap dla klas i metod statycznych ................................................................... 238 Rodzaje bibliotek do tworzenia atrap ................................................................................. 241 Constrained ..................................................................................................................... 241 Unconstrained ................................................................................................................ 241 Constrained czy unconstrained? .................................................................................. 242 Podsumowanie ....................................................................................................................... 243 Poleć książkęKup książkę Spis treści 9 Rozdział 11. Dobre praktyki pisania testów jednostkowych ................................. 245 Test powinien być szybki, bardzo szybki! .......................................................................... 246 Testy powinny być odizolowane i niezależne od siebie .................................................... 247 Test powinien być powtarzalny ........................................................................................... 247 Test powinien być deterministyczny .................................................................................. 248 Test nie powinien mieć zależności zewnętrznych ............................................................. 248 Test nie powinien mieć konfiguracji ................................................................................... 249 Wynik testu nie powinien być interpretowany ................................................................. 249 Test nie powinien być pusty ................................................................................................. 250 Zalążek kodu powinien wyrzucać wyjątek ......................................................................... 250 Test powinien mieć jedną logiczną asercję ........................................................................ 251 Testy nie powinny być dyskryminowane ........................................................................... 251 Testy powinny być podzielone według kategorii .............................................................. 251 Test powinien mieć strukturę Arrange-Act-Assert .......................................................... 251 Test powinien obejmować ścieżki optymistyczne i przypadki brzegowe ...................... 252 Test powinien mieć odpowiednią nazwę ........................................................................... 252 Testowane powinny być tylko publiczne składowe .......................................................... 252 Test powinien oczekiwać konkretnego typu wyjątku ....................................................... 253 Test powinien oczekiwać wyjątku w konkretnym wyrażeniu ......................................... 253 Test nie powinien zawierać instrukcji warunkowych i pętli ............................................ 253 Test powinien mieć wartości oczekiwane wpisane „na sztywno” ................................... 254 Test powinien mieć asercję ................................................................................................... 255 Test powinien być nieskomplikowany ............................................................................... 255 Test nie powinien być „przespecyfikowany” ..................................................................... 256 Test nie powinien zawierać metod z atrybutami SetUp i TearDown ............................. 257 Klasa testowa powinna być bezstanowa ............................................................................. 257 Komunikaty asercji nie powinny być nadmiarowe ........................................................... 258 Podsumowanie ....................................................................................................................... 259 Rozdział 12. TDD i istniejący kod ....................................................................... 261 Refaktoryzacja bezpieczna i mniej bezpieczna .................................................................. 261 Przykład bezpiecznej refaktoryzacji ............................................................................. 264 Dodawanie testów do istniejącego kodu ............................................................................ 271 Gdzie zacząć dodawać testy? ......................................................................................... 271 Jak pisać testy? ................................................................................................................ 272 Narzędzia ......................................................................................................................... 274 Podsumowanie ....................................................................................................................... 275 Poleć książkęKup książkę 10 TDD. Techniki programowania sterowanego testami Rozdział 13. Pokrycie kodu testami ................................................................... 277 Co to jest pokrycie kodu testami? ........................................................................................ 277 Narzędzia do mierzenia pokrycia kodu .............................................................................. 278 W ile procent pokrycia powinniśmy celować? .................................................................. 281 Przykłady „fałszywych” testów o stuprocentowym pokryciu kodu ........................ 281 Podsumowanie ....................................................................................................................... 283 85 , 90 czy 100 ? ...................................................................................................... 283 Pokrycie kodu jako narzędzie do identyfikowania brakujących testów ................. 284 Rozdział 14. Ciągła integracja ........................................................................... 285 Serwer ciągłej integracji ........................................................................................................ 286 Ciągła dostawa i ciągłe wdrażanie ....................................................................................... 288 Podsumowanie ....................................................................................................................... 289 Dodatek A. Biblioteki do testowania ................................................................. 291 Dodatek B. Biblioteki do tworzenia atrap .......................................................... 293 Dodatek C. Biblioteki do mierzenia pokrycia kodu testami .................................. 297 Dodatek D. Testy z danymi zewnętrznymi — przypadek użycia ........................... 299 Dodatek E. Rozszerzalność NUnita ..................................................................... 303 Atrybut informacyjny ........................................................................................................... 305 Atrybut umożliwiający współdzielenie danych ................................................................. 307 Dodatek F. Bibliografia .................................................................................... 311 Źródła internetowe ................................................................................................................ 314 Skorowidz ...................................................................................................... 319 Poleć książkęKup książkę Podziękowania Tę książkę dedykuję mojej fantastycznej Żonie Agnieszce, kochającym Rodzicom oraz wspaniałemu Bratu. Dziękuję Ani Merak, Łukaszowi Oliwie i Patrykowi Spytkowskiemu za wysiłek włożony w dodatkową korektę książki. Dziękuję też Markowi Krzemińskiemu za pomysł na książkę i motywację do jej pisania. Chciałbym też podziękować całej mojej rodzinie, wszystkim przyjaciołom, współpracowni- kom oraz ludziom, z którymi zamieniłem parę zdań czy kilka słów. Dziękuję też Tobie, Czytelniku, że zdecydowałeś się na lekturę tej książki. Mam ogromną nadzieję, że znajdziesz tutaj wiele informacji, które wykorzystasz w swojej pracy pro- gramisty i rozwoju w tym kierunku. Mam też nadzieję, że lektura tej książki będzie dla Ciebie czystą przyjemnością! Poleć książkęKup książkę 12 TDD. Techniki programowania sterowanego testami Poleć książkęKup książkę Przedmowa Jakie jest najważniejsze zadanie programisty? Jedni powiedzą, że napisanie działającego kodu. Ja uważam jednak, że działający kod jest jedynie efektem ubocznym naszej pracy. Przede wszystkim powinniśmy tworzyć kod utrzymywalny. Dzięki temu poprawienie niedziałających rozwiązań nie stanowi karkołomnego wyczynu na miarę wyprawy na Mount Everest, a rozwijanie systemów informatycznych staje się procesem przewidywal- nym, przyjemnym i — co niezmiernie istotne — jego koszt jest niezmienny w czasie. Testowanie oprogramowania to praktyka wspomagająca nas w tych staraniach. Jedne środowiska bezdyskusyjnie stosują i promują pisanie testów, nieustannie dbając o swój rozwój w tym zakresie. Inne natomiast kwestionują sensowność takiego podejścia. Negatywne nastawienie programistów do pisania testów często wynika z niewiedzy i braku odpowiedniej ścieżki nauki. Jest to trudna umiejętność, wymagająca praktyki i nakładu czasu. Niejednokrotnie trzeba popełnić wiele błędów i wyciągnąć z nich wnioski, by finalnie odnieść długoterminowe korzyści. Aspekt edukacji w zakresie tej sztuki jest często po- mijany, a bez tego żadna zaawansowana technika nie ma szans na spełnienie oczekiwań. Testy nie są lekiem na całe zło. Samo ich pisanie nie gwarantuje natychmiastowego wy- eliminowania błędów. Dopiero stopniowe, świadome i konsekwentne pogłębianie wie- dzy skutkuje usprawnieniem procesu wytwarzania oprogramowania oraz niezmiernie ułatwia jego rozwój, utrzymanie i modyfikację. Umiejętność pisania wartościowych testów jednostkowych to jedna z najpewniejszych inwestycji, na jaką może zdecydować się programista. — Maciej Aniserowicz, autor książki Zawód: Programista i bloga devstyle.pl Poleć książkęKup książkę 14 TDD. Techniki programowania sterowanego testami Poleć książkęKup książkę Cytaty o TDD Kod bez testów to zły kod. Nie ma znaczenia, jak dobrze jest napisany; nie ma znaczenia, jaki jest ładny, jak bardzo zorientowany obiektowo czy też jak mocno hermetyczny. Za pomocą testów możemy zmienić zachowanie naszego kodu szybko i w sposób weryfikowalny. Bez nich tak naprawdę nie wiemy, czy kod zmierza ku lepszemu czy ku gorszemu. — Michael Feathers, Praca z zastanym kodem. Najlepsze techniki TDD nie jest po to, by pisać dobry kod, lecz raczej po to, by nie pisać złego kodu. — Nat Pryce, Growing Object Oriented System Guided by Tests Zdarza się często — i zdarzać się będzie — że TDD implementowane jest w kodzie nie- wyposażonym w należyty zestaw testowy. A jeżeli tak, to może się również zdarzyć, że przy refaktoryzacji kodu popełnisz błąd i nie zostanie on wykryty, bo wszystkie istniejące testy nadal będą zaliczane. Refaktoryzacja stanie się więc niepewna, zatem ograniczysz ją do minimum. Twój pro- jekt stanie się zagmatwany i także niepewny, Twoje samopoczucie się pogorszy, Twoja produktywność spadnie, zostaniesz zwolniony z pracy. Opuści Cię Twój pies, przestaniesz się należycie odżywiać. Nabawisz się awitaminozy, szkorbutu i chorób przyzębia. Zatem, przynajmniej w trosce o swe uzębienie, myśl retroaktywnie o testowaniu przed refakto- ryzacją. — Kent Beck, TDD. Sztuka tworzenia dobrego kodu Najlepszym znanym mi sposobem pisania kodu jest kształtowanie go od początku za pomocą testów. — Ron Jeffries, jeden z twórców programowania ekstremalnego Najlepsze w TDD jest to, że metoda ta zapewnia, iż kod robi to, co programista myśli, że kod powinien robić. — James Grenning Poleć książkęKup książkę 16 TDD. Techniki programowania sterowanego testami Testy czarnej skrzynki dowodzą, że kod pisany z zastosowaniem metody TDD ma lepszą jakość niż kod pisany według tradycyjnego, kaskadowego modelu. — Boby George i Laurie Williams, An Initial Investigation of Test Driven Development in Industry Kiedy ludzie pytają mnie, jak pisać lepszy kod, zawsze im odpowiadam: pisz testy jed- nostkowe. (…) Testowanie kodu nauczy cię, jak budować oprogramowanie. — Scott Allen Poleć książkęKup książkę Wstęp W języku japońskim istnieje pojęcie kaizen, które utożsamiane jest z filozofią nieustannych małych kroków i drobnych poprawek. Jest to przeciwieństwo filozofii kaikaku, która oznacza radykalną zmianę. Zastanówmy się nad słowem kluczem, którym jest zmiana. Zmiana dla programisty może oznaczać nie tylko zmianę zawodu, technologii, stosowanych narzędzi, ale także zmianę w procesie wytwarzania oprogramowania czy zmianę metody programowania. Zacznijmy od tej dużej zmiany, rewolucyjnej, kaikaku. Przykład? Wdrożenie frameworku Scrum w zespole. Przed wdrożeniem zespół znajduje się w sytuacji, do której jest przy- zwyczajony, nie ponosi żadnego ryzyka związanego ze zmianami, doskonale wie, co go czeka dnia następnego. Status quo jest nienaruszone. Gdy pojawia się chęć zmian — a te często wprowadzane są odgórnie (element obcy) — rodzi się opór wewnątrz zespołu. Niekiedy nieznane są powody zmian, a bardzo często nie są znane również podstawy i wartości, które kryją się za tymi zmianami. Duże zmiany mogą stwarzać niekomfortowe warunki i powodować irracjonalne zachowania, których efektem jest na przykład lekce- ważenie nowego procesu czy brak chęci do jego zrozumienia. Po tym etapie następuje faza chaosu, w której zespół zdaje się pracować poza jakąkolwiek kontrolą. Spotkania przebiegają często bez ładu i składu. Zespół może obrać strategię powrotu do poprzed- niego stanu za wszelką cenę lub strategię jak najszybszego wyjścia z tego stanu. Bywa, że te dwie strategie przenikają się w ramach zespołu i formują się dwa bastiony: jeden gotowy na zmiany, a drugi pragnący powrotu do stanu sprzed wprowadzenia zmian. Wraz z po- jawieniem się idei zmian zespół zaczyna wychodzić z chaosu, a proces zmiany się stabili- zuje. Gdy nowe pomysły zostaną zintegrowane, rodzi się nowe status quo, nowy stan, nowa strefa komfortu. Jest to wzorcowy model według teorii Virginii Satir (rysunek W.1) [Appelo, 2010; Goździe- niak, 2015; Brodziński, 2015]. Powyższy scenariusz wiąże się z wprowadzeniem zbyt du- żej zmiany bądź zbyt dużej ilości zmian, oczekiwaniem zbyt krótkiego czasu na poprawę efektywności oraz wprowadzeniem zmian bez moderacji lub z moderacją nieudolną. Ozna- cza to również ryzyko w związku z wprowadzeniem zmiany, gdyż na etapie chaosu ze- spół może wycofać się ze zmian i powrócić do swojego poprzedniego stanu. Poleć książkęKup książkę 18 TDD. Techniki programowania sterowanego testami RYSUNEK W.1. Model zmian według Virginii Satir1 Ale czy tak zawsze musi wyglądać każda zmiana? W podejściu ewolucyjnym, kaizen, stosujemy metodę niewielkich kroków. Wdrożenie Scruma? Można to zrobić w następujący sposób:  Zespół analizuje poszczególne elementy Scruma i zaczyna je stosować, ale niekoniecznie wszystkie naraz.  Zespół i kierownictwo nie powinny oczekiwać natychmiastowych efektów i błyskawicznego wzrostu wydajności.  Zespół zbiera informacje zwrotne dotyczące każdej zmiany i adaptuje je do aktualnego środowiska.  Jeżeli zastosowanie pewnej zmiany w pewnym czasie wpłynęło negatywnie na zespół, można rozważyć ponowną próbę jej wprowadzenia. Ta sama praktyka, która nie zadziałała wcześniej, może okazać się skuteczna w nowym kontekście.  Nie każda zmiana wpływa pozytywnie na proces, ale dzięki temu, że jest mała, zespół uzyskuje szybką informację zwrotną na jej temat i może szybciej zareagować i zaadaptować się do nowej sytuacji. 1 Na podstawie: https://www.flickr.com/photos/jurgenappelo/5201852636/in/album- 72157625328824303/ Poleć książkęKup książkę Wstęp 19 Główna idea filozofii kaizen to drobne poprawki w procesie. Pozwalają one skutecznie wyeliminować fazę chaosu w modelu zmiany i nie wiążą zmiany z nagłą degradacją wy- dajności. Model małych zmian naniesiony na model Virginii Satir został przedstawiony na rysunku W.2. RYSUNEK W.2. Dzięki filozofii małych zmian, kaizen, możemy uniknąć etapu chaosu i utrzymać coraz lepszą efektywność w czasie Należy pamiętać o jeszcze jednej, bardzo ważnej kwestii. Otóż nie ma globalnego optimum, do którego moglibyśmy zmierzać, są za to lokalne optima. A zatem zmiana procesu i jego poprawa to proces nieustanny, ciągły2. Kaizen i kaikaku to nie tylko zmiany zespołowe i nie tylko związane z procesem tworze- nia oprogramowania. Filozofię małych kroków, drobnych poprawek i unikania nagłych, dużych zmian można przenieść na grunt życia osobistego i własnego rozwoju. Test-Driven Development — najpierw piszemy test, później kod, a na końcu dokonuje- my refaktoryzacji. Cykl bardzo zwięzły i prosty do zapamiętania, prawda? Tak, to prawda. Z TDD związana jest jednak konieczność zmiany… Przewodnik po książce Niniejsza książka podzielona jest na rozdziały, które umożliwiają efektywną naukę, wpro- wadzając Czytelnika w metodę Test-Driven Development krok po kroku. Pierwszy rozdział jest wprowadzeniem do tematyki TDD. Opisuję w nim historyczny kontekst tej metody i podstawy, na których ją wykreowano. Szybko dowiesz się, czym jest cykl Red-Green-Refactor, i poznasz sposób pisania według tej techniki. 2 Jeśli ciekawi Cię ten proces, to polecam wyszukać w internecie hasło fitness landscapes. Poleć książkęKup książkę 20 TDD. Techniki programowania sterowanego testami W kolejnych rozdziałach przejdziemy do rozważań teoretycznych, w których skupimy się na tym, jakie korzyści może nam przynieść TDD, a z czym mogą być kłopoty. Przyj- rzymy się też najczęściej zadawanym pytaniom, na które niekiedy nie ma jedynej dobrej odpowiedzi. Następnie przejdziemy do tematów praktycznych. Napiszemy pierwsze testy jednostko- we i przyjrzymy się dokładnie bibliotece do testowania i bibliotece do tworzenia atrap. Potem omówię wzorce i antywzorce w świecie testów jednostkowych. Dowiesz się również, jakie strategie zastosować w pracy z kodem już istniejącym. W dwóch ostatnich rozdziałach omówię pokrycie kodu testami oraz systemy ciągłej in- tegracji, ciągłej dostawy i ciągłego wdrażania. W pięciu dodatkach do książki zamieściłem informacje na temat bibliotek do testowa- nia, tworzenia atrap i mierzenia pokrycia kodu dla .NET. Omówiłem również scenariusz testów z danymi zewnętrznymi i bardzo prosty przykład sposobu rozszerzenia biblioteki NUnit o nowe funkcje. Dla kogo jest ta książka? Książka jest skierowana głównie do programistów chcących poznać metodę TDD i testy jednostkowe. W jakim stopniu muszę umieć programować? Warunkiem koniecznym do zrozumienia idei zawartych w tej książce jest podstawowe doświadczenie w zakresie programowania zorientowanego obiektowo. TDD wymaga myślenia obiektowego, a zatem Czytelnik powinien znać podstawy obiektowości. Nie jestem programistą C#. Czy ta książka ma jakąś wartość dla mnie? Część teoretyczna książki jest uniwersalna i ma zastosowanie w przypadku każdego ję- zyka programowania. Część praktyczna również, ale wymaga zrozumienia języka C#. Ćwiczenia praktyczne można wykonywać poprzez analogię do rozwiązań występują- cych w bibliotece tego właśnie języka. A zatem odpowiedź brzmi: tak! Przykłady zawarte w tej książce napisane są w języku C#, ale nie znaczy to, że jedynie programiści tego ję- zyka mogą z niej korzystać. C# jest językiem prostym w czytaniu i rozumieniu. Rozdziały traktujące o konkretnych rozwiązaniach w bibliotekach NUnit i Moq zostały zatytułowane tak, aby osoba szukają- ca informacji dla innej biblioteki i innego języka mogła znaleźć je w prosty i bezbolesny sposób. W gestii Czytelnika pozostaje wyszukanie odpowiednika w stosowanej przez niego Poleć książkęKup książkę Wstęp 21 bibliotece. Pisząc tę książkę, miałem to na względzie i wyszukiwałem analogiczne tematy, ale dla innych bibliotek. Przykładem jest rozdział z NUnitem i testami parametryzowanymi. Chcąc odnaleźć tę samą funkcję dla biblioteki JUnit (Java), należy wpisać w wyszukiwarce internetowej frazę JUnit Parameterized tests. Zazwyczaj pierwsze rezultaty będą pro- wadzić do dokumentacji biblioteki lub odpowiedzi na Stack Overflow, a to w zupełności wystarczy. Co, jeśli moja ulubiona biblioteka w moim ulubionym języku nie oferuje funkcji zawar- tej w książce? Cóż, jeżeli jesteś dobrym programistą, nie będzie to dla Ciebie przeszkodą. W takiej sytuacji możesz wykonać jeden z następujących kroków:  wykorzystanie innych funkcji języka programowania lub biblioteki, aby osiągnąć ten sam cel;  własna implementacja funkcji w bibliotece;  własna implementacja funkcji w bibliotece i kontakt z autorem biblioteki, a jeśli jest to biblioteka oparta na otwartym źródle, pull request do repozytorium;  stworzenie własnej biblioteki. Jeśli implementacja jest zbyt trudna, biblioteka nie jest oparta na otwartym źródle lub nie masz czasu na dopisanie nowych funkcji, to pozostaje kontakt z innymi programi- stami, np.:  wspólna sesja w ramach swojego zespołu programistycznego i kolektywna próba rozwiązania problemu;  kontakt z autorem biblioteki i pytanie o możliwe rozwiązania;  kontakt ze społecznością, np. Stack Overflow, repozytorium danej biblioteki na GitHubie (społeczność anglojęzyczna), 4programmers.net (społeczność polskojęzyczna). Umiem pisać testy jednostkowe i znam TDD. Czy ta książka jest dla mnie? Testy jednostkowe można pisać według techniki TDD lub bez jej stosowania. Bardzo często, gdy prowadziłem ćwiczenia z tego tematu, okazywało się, że programista po- twierdzający znajomość TDD tak naprawdę nie stosował cyklu Red-Green-Refactor. Co więcej, był zaskoczony iteracyjnym podejściem do pisania kodu, co jest przecież klu- czową kwestią w TDD. A zatem nie do końca znał TDD. Ponadto testy jednostkowe można pisać podobnie jak kod, ale jak zweryfikować, czy są one poprawne i cechuje je wysoka jakość? Czy aby na pewno wszystkie zależności są za- stąpione atrapami? A co z kwestiami pokrycia kodu testami i ciągłej integracji? Czy Twój Poleć książkęKup książkę 22 TDD. Techniki programowania sterowanego testami zespół ma postawiony cel osiągnięcia określonego pokrycia kodu testami? Czy ma to sens? Czy za każdą zmianą w repozytorium uruchomiony zostaje cały zestaw testów jednostkowych dla aplikacji? W istocie, praktykując dane zagadnienie, często robimy to źle lub moglibyśmy robić to lepiej. Skąd możemy otrzymać informację zwrotną na temat ewentualnych poprawek? Możemy przedyskutować pewne zagadnienia w ramach zespołu, możemy taką dyskusję przeprowadzić z innymi programistami i innymi zespołami, możemy również zdać się na własną analizę tematu i wykorzystać dostępne źródła. Ta książka pozwala zrozumieć wiele kwestii, które bywają pomijane w rozważaniach o testach automatycznych. Jest to jedno ze źródeł, które dostarczy Ci informacji zwrotnej na temat tego, czy wykonujesz swoją pracę prawidłowo. Warto zrobić rachunek sumienia i spróbować zidentyfikować brakujące obszary wiedzy w zakresie testowania automatycznego, testów jednostkowych i Test-Driven Development. A ta książka Ci w tym pomoże! Jestem menadżerem/dyrektorem/właścicielem (a więc nie programuję), a mój zespół chce wdrożyć TDD. Czy z tej książki dowiem się, czy warto? Książka jest skierowana do programistów i mocno przesiąknięta kodem źródłowym. Jeśli interesuje Cię Test-Driven Development z punktu widzenia czysto biznesowego, to te- mu zagadnieniu poświęconych jest kilka rozdziałów. Przede wszystkim zachęcam do przejrzenia biznesowych przypadków użycia, które umieściłem w książce. Scenariusze, w których nie ma czasu na TDD i testy automatyczne, brakuje czasu na naukę nowych technik, trzeba dostarczać oprogramowanie szybko i na czas, są bardzo typowe dla bran- ży programistycznej i poświęciłem tym zagadnieniom kilka podrozdziałów. W szczegól- ności pomocne będą następujące podrozdziały: „Błędy w oprogramowaniu” (rozdział 1.), „Co zyskujemy dzięki TDD?” (rozdział 2.) oraz „Trudności przy wdrażaniu TDD” (roz- dział 3.). Jestem manualnym testerem. Czy powinienem znać TDD? Test-Driven Development to technika dla programisty. Jeśli jesteś testerem ręcznym i inte- resujesz się tematyką programowania oraz chcesz rozwijać to zainteresowanie, to ta książka jest również dla Ciebie. Bardzo dobrą techniką nauki jest coding dojo (więcej na jej temat przeczytasz w podroz- dziale „Ścieżka nauki” rozdziału 3.). Jeżeli Twój zespół praktykuje dojo lub ćwiczenia o podobnej formie, nie wahaj się dołączyć. Programiści są zazwyczaj pomocni i z chęcią dzielą się swoją wiedzą z innymi. Znam przypadki, w których w coding dojo uczestniczył cały zespół, łącznie z testerami ręcznymi, analitykiem biznesowym i… menadżerem! Nie Poleć książkęKup książkę Wstęp 23 wszyscy na co dzień pracowali w środowisku programistycznym, ale to nie jest istotne. Istotne jest stworzenie środowiska do nauki, w którym osoby zarówno mniej, jak i bardziej doświadczone mogą uczestniczyć we wspólnym procesie tworzenia oprogramowania. A jeżeli zespół nie praktykuje coding dojo, zachęcam do podjęcia tematu i zaproponowania takich sesji (jedna godzina tygodniowo powinna być łatwa do wygospodarowania). Kontekst jest królem Context is king, w języku polskim „kontekst jest królem”, to znane powiedzenie, które bardzo lubię. Wskazuje ono, jak bardzo istotne jest zrozumienie kontekstu danego pojęcia. Test-Driven Development to dziedzina, w której pojęcia nie są unormowane i bywają używane zamiennie, w zależności od kontekstu. Doskonale obrazuje ten fakt tabela 10.3 umieszczona w podrozdziale „Klasyfikacja atrap” rozdziału 10. W jednym kontekście (książki, aplikacji, źródła internetowego) to samo pojęcie może mieć inne znaczenie niż w innym kontekście. Jest to źródłem wielu problemów ze zrozumieniem pewnych sche- matów. A, paradoksalnie, Test-Driven Development ma przecież służyć rozwiązywaniu problemów z niejednoznacznością wymagań biznesowych i zawartych w nich pojęć. Poza nomenklaturą związaną z klasyfikacją atrap istnieje jeszcze kilka pojęć, które chciałbym omówić, aby ich rozumienie było całkowicie jednoznaczne. Atrapa to mock czy test double? W niniejszej książce atrapa to test double, czyli zamiennik zależności, którą chcemy imito- wać. Do grupy atrap należą wszystkie typy test double, czyli dummy, stub, fake, mock, spy itd. (niektóre źródła czy biblioteki mogą zawierać jeszcze inne typy atrap). Należy mieć to na uwadze z dwóch powodów. Po pierwsze, biblioteka do tworzenia atrap, którą opisuję w tej książce, to Moq. W Moqu nie ma rozróżnienia na typy atrap, a wszystko, co tworzymy za pomocą tej biblioteki, jest mockiem. Zatem w kontekście tej biblioteki mock to atrapa, a atrapa to mock. W pracy nad atrapami w polskojęzycznych zespołach rzadko stosuje się polskie słowo „atrapa” czy angielskie wyrażenie test double, dlatego używam spolszczenia „mockować”. Po drugie, polska Wikipedia tłumaczy hasło mock object z angielskiej wersji encyklope- dii jako „atrapa obiektu”. Hasło test double nie ma natomiast odpowiednika w polskoję- zycznej Wikipedii. W literaturze polskiej test double zwykle nie ma tłumaczenia, a pojęcie to występuje na przykład jako obiekt test double [Martin, 2010]. Tłumaczenia pojęć mock i test double w kontekście niniejszej książki przedstawia tabela W.1. Poleć książkęKup książkę 24 TDD. Techniki programowania sterowanego testami TABELA W.1. Tłumaczenia pojęć mock i test double w kontekście niniejszej książki Pojęcie (j. ang.) Kontekst test double mock Tłumaczenie na j. polski atrapa niniejsza książka w kontekście ogólnym niniejsza książka w kontekście biblioteki Moq atrapa, mock jeden z typów test double imitacja xUnit a xUnit.net xUnit to rodzina bibliotek do tworzenia testów jednostkowych. Powstały one na bazie opracowanego w 1998 roku przez Kenta Becka frameworku SUnit dla języka Smalltalk. xUnit.net to jedna z bibliotek do tworzenia testów jednostkowych dla frameworku .NET. Funkcja a funkcjonalność oraz funkcyjny a funkcjonalny W języku polskim słowo „funkcjonalność” bywa niekiedy używane jako synonim słowa „funkcja”. Oto co można przeczytać na ten temat w Poradni Językowej PWN: „(…) rozróżnienie na funkcję i funkcjonalność w języku specjalistycznym nie wzięło się znikąd — w świecie IT czym innym jest funkcja, a czym innym funkcjonalność. Jednak zwykłym ludziom, którzy korzystają z karty kredytowej, Facebooka czy smartfona po to, by ułatwić sobie życie, odróżnienie na funkcję i funkcjonalność zapewne nie jest potrzebne. Możliwość robienia zdjęć telefonem komórkowym jest dla mnie funkcją tego telefonu, mimo że jego sprzedawca próbował mnie przekonać, że to jego funkcjonalność. Dla informatyka funkcja jest terminem, który znaczy trochę coś innego niż dla osoby, która nie zna tej terminologii. Zawsze na styku takich użyć (specjalistyczne — niespecjalistyczne) dojdzie do pewnych nieścisłości (np. potocznie używa się nazwy depresja na oznaczenie bardzo złego nastroju, a dla lekarza jest to choroba mająca określone cechy) i nic na to nie poradzimy”. [Kłosińska, 2017] W niniejszej książce zastosowałem się do zacytowanej rady, a zatem nie mówimy o funk- cjonalnościach aplikacji, lecz o jej funkcjach. Funkcja ma też znaczenie programistyczne w kontekście podprogramu. Istnieją również pojęcia „język funkcyjny” i „test funkcjonalny”. Ich definicje zamieściłem w tabeli W.2. Poleć książkęKup książkę Wstęp 25 TABELA W.2. Definicje pojęć zastosowanych w książce związanych z funkcją, funkcyjnością i funkcjonalnością Pojęcie funkcja język funkcyjny test funkcjonalny Kontekst 1) zadanie, które spełnia dana rzecz (mylone z funkcjonalnością danej rzeczy) 2) wydzielona część programu, podprogram odmiana programowania deklaratywnego test oparty na elementach, które są bezpośrednio związane z funkcją aplikacji Synonimy Jeśli chodzi o pozostałe kwestie językowe, poniższe pojęcia są w niniejszej książce stoso- wane wymiennie, chociaż nie zawsze są synonimami:  biblioteka, framework;  program, aplikacja, projekt, system;  API, interfejs programowania aplikacji;  implementacja, logika biznesowa;  test spełniony, test green, test zielony itp.;  test niespełniony, test red, test czerwony itp. Jak uczyć się metody Test-Driven Development? TDD jest metodą, która wymaga nauki zarówno w kwestiach teoretycznych, jak i prak- tycznych. Owszem, sam cykl jest łatwy do zapamiętania i na rozmowie o pracę szybko go powtórzymy: najpierw test, później kod, a na koniec refaktoryzacja! Proste, prawda? Aby nauczyć się tej metody lub polepszyć swoje umiejętności w tym zakresie, należy przede wszystkim sporo ćwiczyć. Książka zawiera sporo przykładów praktycznych, których zrozumienie może okazać się trudne przez samo czytanie. Dlatego zachęcam do wyko- nania analogicznych kroków, eksperymentowania i zabawy z kodem, który jest opisany w danym dziale. Wymaga to więcej czasu, ale sprawia, że proces uczenia się jest bardziej efektywny. Czy należy przepisać każdą linijkę kodu zawartą w książce? Nie, bynajmniej! Najlepiej, rozpoczynając lekturę książki, stworzyć własną solucję, która będzie swoistą pia- skownicą, miejscem służącym do uruchamiania testów i eksperymentowania z kodem. Co można zrobić po przeczytaniu książki, aby lepiej poznać tematykę? Jeśli zaczniesz stosować TDD w praktyce, Twoja wydajność może z początku być niższa. Jest to natu- ralne w procesach nauki, i to nie tylko tych powiązanych z programowaniem. Z czasem Twoja wydajność będzie wzrastać, a korzyści płynące ze stosowania TDD, takie jak lep- sza jakość kodu i mniejsza ilość defektów, staną się widoczne. Poleć książkęKup książkę 26 TDD. Techniki programowania sterowanego testami Dobrze jest szukać miejsca do zastosowania TDD w swoim miejscu pracy, jeśli metoda ta nie jest jeszcze praktykowana (należy jednak przedyskutować taką decyzję z zespołem i przełożonym). Nic nie stoi na przeszkodzie, aby zastosować TDD również do swoich własnych projektów. A jeżeli nie mamy własnego projektu, to możemy taki wymyślić, stworzyć i go opublikować lub po prostu wyrzucić. Nie musi to być skomplikowany projekt, wystarczy mały zestaw pomocniczych metod. Chodzi o to, aby metodykę TDD praktykować po przeczytaniu tej książki. Warto też zastanowić się nad stworzeniem miejsca do nauki i rozwoju w swoim miejscu pracy. I nie mówię tutaj tylko o TDD. Wspólne dyskusje, prezentacje, ćwiczenia (np. co- ding dojo, kata) związane z programowaniem, testowaniem aplikacji i dziedzinami po- chodnymi co najmniej raz w tygodniu przez godzinę mogą przynieść sporo korzyści obecnemu projektowi. To na tego typu spotkaniach mogą zrodzić się pomysły na udo- skonalenie aplikacji w zakresie jej testowania, automatyzacji, jakości itd. Nie musi to też być kontekst projektu, nad którym się obecnie pracuje. Nauka TDD, ATDD, BDD, pro- gramowania funkcyjnego itp. może również przynieść wymierne efekty, jeśli wartość biznesowa tej nauki zostanie przeniesiona na grunt projektu. Wymiar nauki ma także aspekt rozwojowy. Dziedzina programowania jest skomplikowana i dynamiczna, a wspólna nauka może podnieść kwalifikacje zespołowe. Dlatego gorąco zachęcam do jej praktykowa- nia (pamiętać należy o akceptacji ze strony przełożonego i zaproszeniu go do udziału). Nie należy również zapominać o takich praktykach jak inspekcje kodu i programowanie w parach, pozwalają one bowiem podnieść poziom osób uczących się różnych zagad- nień, w tym również metody TDD. Dogmat Głównym tematem książki jest TDD, ale czy to oznacza, że zawsze należy korzystać z tej metodyki? Odpowiedź brzmi: nie! Co w przypadku, gdy ktoś preferuje pisanie testów jednostkowych po napisaniu imple- mentacji (odwrotnie niż w TDD), ale uzyskuje w efekcie kod wysokiej jakości i bardzo dobre pokrycie testami? A co, jeśli projekt jest pokryty w 100 testami akceptacyjnymi i jednocześnie ma wysokiej jakości kod? Czy wówczas powinno się narzucić w projekcie pisanie testów jednostkowych i stosowanie TDD? Należy pamiętać, że stosowanie TDD i pokrycie testami jednostkowymi stanowią drogę do celu, jakim są wysoka jakość kodu, brak obaw przed wprowadzeniem zmiany do sys- temu oraz niska liczba defektów. Cel ten można realizować za pomocą innych strategii, ta- kich jak Test-After Development lub Behavior-Driven Development. Dobre pokrycie testami jednostkowymi jest jednym ze sposobów (obecnie najpopularniejszym) na dotarcie do tego celu, nie zaś celem samym w sobie. Poleć książkęKup książkę Wstęp 27 Wiele kwestii z zakresu metody Test-Driven Development charakteryzuje się dowolno- ścią, dlatego decyzja o ich zastosowaniu należy do programisty lub zespołu. Przykładowo: czy powinno się tworzyć architekturę aplikacji w taki sposób, aby kod był testowalny? W tej książce napisałem, że nie powinno się testować niepublicznych składowych klasy (poza kil- koma wyjątkami). Można zadać kilka pytań w tej materii:  Czy kod powinien mieć publiczne API po to tylko, aby był testowalny?  Cz
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

TDD. Techniki programowania sterowanego testami
Autor:

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: