{"id":31630,"date":"2019-07-30T07:13:52","date_gmt":"2019-07-30T05:13:52","guid":{"rendered":"https:\/\/nearshore-it.eu\/artykuly\/test-driven-development-na-co-dzien\/"},"modified":"2024-10-03T16:49:35","modified_gmt":"2024-10-03T14:49:35","slug":"test-driven-development-na-co-dzien","status":"publish","type":"post","link":"https:\/\/nearshore-it.eu\/pl\/artykuly\/test-driven-development-na-co-dzien\/","title":{"rendered":"Test-Driven Development (TDD) na co dzie\u0144"},"content":{"rendered":"\n<div class=\"table-of-contents\">\n    <p class=\"title\">Przejd\u017a do:<\/p>\n    <ol>\n                    <li><a href=\"#test-driven-development\">1.  Test-Driven Development<\/a><\/li>\n                    <li><a href=\"#brak-stosowania-tdd-case-study\">2.  Brak stosowania TDD \u2013 case study<\/a><\/li>\n                    <li><a href=\"#schemat-ideowy-test-driven-development\">3.  Schemat ideowy Test-Driven Development<\/a><\/li>\n                    <li><a href=\"#jak-minimalizowac-liczbe-testow\">4.  Jak minimalizowa\u0107 liczb\u0119 test\u00f3w?<\/a><\/li>\n                    <li><a href=\"#stosuj-parametryzacje\">5.  Stosuj parametryzacj\u0119<\/a><\/li>\n                    <li><a href=\"#zadbaj-o-czytelnosc-testow-jednostkowych\">6.  Zadbaj o czytelno\u015b\u0107 test\u00f3w jednostkowych<\/a><\/li>\n                    <li><a href=\"#korzysci-z-tdd-dla-klienta-i-developera\">7.  Korzy\u015bci z TDD dla klienta i developera<\/a><\/li>\n                    <li><a href=\"#podsumowanie\">8.  Podsumowanie<\/a><\/li>\n            <\/ol>\n<\/div>\n\n\n<h2 class=\"wp-block-heading\" id=\"test-driven-development\">Test-Driven Development<\/h2>\n\n\n\n<p>TDD to jedna z technik zwinnego wytwarzania oprogramowania. Technika Test-Driven Development, kt\u00f3rej autorem jest Kent Beck, jeden z autor\u00f3w Agile Manifesto, polega na wielokrotnym powtarzaniu cyklu Red \u2013 Green \u2013 Refactor, o czym pisz\u0119 poni\u017cej. Tym, co wyr\u00f3\u017cnia technik\u0119 Test-Driven Development, jest to, \u017ce programista rozpoczyna prac\u0119 od pisania test\u00f3w jeszcze nienapisanej funkcji. Pozwala tak\u017ce na dodawanie jakiejkolwiek nowej funkcjonalno\u015bci do rozwijanej aplikacji, minimalizuj\u0105c ryzyko pojawienia si\u0119 przypadkowych b\u0142\u0119d\u00f3w w niezmodyfikowanych obszarach programu, o kt\u00f3rych powi\u0105zaniach po kilku miesi\u0105cach mogli\u015bmy zapomnie\u0107. <strong>Jedn\u0105 z&nbsp;zalet Test-Driven Development jest to, \u017ce&nbsp;modyfikuj\u0105c lub dodaj\u0105c funkcjonalno\u015b\u0107, automatycznie otrzymujemy raporty o&nbsp;wszystkich powi\u0105zanych obszarach, popsutych przez&nbsp;nasze zmiany.<\/strong> Daje to szans\u0119, by szybko je poprawi\u0107 i nie dopu\u015bci\u0107 do ich wdro\u017cenia wraz z funkcjonalno\u015bci\u0105. Podej\u015bcie Test-Driven Development pozwala projektowa\u0107 zaawansowane wzorce i dzi\u0119ki automatyzacji sprawia, \u017ce design aplikacji lub oprogramowania jest czytelny i przejrzysty. Sczeg\u00f3lnie dobrze sprawdzaj\u0105 si\u0119 w przypadku rozbudowanych projekt\u00f3w. O Test-Driven Development mo\u017cna by pisa\u0107 du\u017co \u2013 w tym artykule chcia\u0142bym skupi\u0107 si\u0119 na stosowaniu TDD w praktyce oraz korzy\u015bciach p\u0142yn\u0105cych z tego podej\u015bcia.<\/p>\n\n\n\n<p><strong>Przeczytaj tak\u017ce:<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong><a href=\"http:\/\/jcommerce.local\/jpro\/artykuly\/testy-bdd-czy-naprawde-sa-potrzebne\" target=\"_blank\" rel=\"noreferrer noopener\">Czym jest BDD \u2013 Behavior Driven Development?<\/a><\/strong><\/li>\n\n\n\n<li><a href=\"http:\/\/jcommerce.local\/jpro\/artykuly\/automatyzacja-testow-obalamy-mity\" target=\"_blank\" rel=\"noreferrer noopener\"><strong>Automatyzacja test\u00f3w \u2013 obalamy mity<\/strong><\/a><\/li>\n\n\n\n<li><strong>Minimalistyczny\u00a0<\/strong><a href=\"http:\/\/jcommerce.local\/jpro\/artykuly\/minimalistyczny-przypadek-testowy\" target=\"_blank\" rel=\"noreferrer noopener\"><strong>przypadek testowy<\/strong><\/a><\/li>\n<\/ul>\n\n\n\n<p><\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"brak-stosowania-tdd-case-study\">Brak stosowania TDD \u2013 case study<\/h2>\n\n\n\n<p>Przed&nbsp;laty, gdy&nbsp;stawia\u0142em pierwsze kroki jako programista, trafi\u0142em do&nbsp;projektu, w&nbsp;kt\u00f3rym&nbsp;wsp\u00f3lnie z&nbsp;koleg\u0105 po&nbsp;fachu mieli\u015bmy za&nbsp;zadanie stworzy\u0107 dedykowany konfigurator dla producenta okien. Sam fakt z\u0142o\u017cono\u015bci technologicznej produkcji okien powinien zdeterminowa\u0107 maksymaln\u0105 przezorno\u015b\u0107. U\u017cytkownik aplikacji m\u00f3g\u0142 skonfigurowa\u0107 okno, bazuj\u0105c na&nbsp;parametrach zar\u00f3wno standardowych, jak i&nbsp;niestandardowych. W&nbsp;zale\u017cno\u015bci od&nbsp;wymiar\u00f3w pewne opcje by\u0142y dost\u0119pne lub nie. U\u017cytkownik mia\u0142 do&nbsp;pokonania kilka-kilkana\u015bcie krok\u00f3w z&nbsp;wieloma mo\u017cliwo\u015bciami dla ka\u017cdego. Na&nbsp;ostateczn\u0105 cen\u0119 wp\u0142ywa\u0142y r\u00f3\u017cne opcje i&nbsp;czynniki.<\/p>\n\n\n\n<p>W&nbsp;projekcie tym zaobserwowa\u0142em co najmniej kilka nie&nbsp;najlepszych praktyk, np.&nbsp;brak kodu testuj\u0105cego czy&nbsp;<em>code review<\/em>. Manager i&nbsp;klient nie&nbsp;wiedzieli jednak, \u017ce&nbsp;w&nbsp;miar\u0119 mo\u017cliwo\u015bci starali\u015bmy si\u0119 recenzowa\u0107 prac\u0119, kt\u00f3r\u0105 dostarczali\u015bmy, a&nbsp;kt\u00f3rej&nbsp;efekty by\u0142y przeznaczone do&nbsp;stosowania bezpo\u015brednio na&nbsp;\u015brodowisku produkcyjnym.<\/p>\n\n\n\n<p>Przez ca\u0142y czas pracy przy projekcie czu\u0142em, \u017ce dzia\u0142am pod ogromn\u0105 presj\u0105. Nie polemizowa\u0142em, gdy powiedziano mi, \u017ce w j\u0119zyku PHP (w kt\u00f3rym pisali\u015bmy), nie przeprowadza si\u0119 test\u00f3w jednostkowych. W efekcie kod, kt\u00f3ry po modyfikacjach rozbudowywali\u015bmy, wymaga\u0142 wielokrotnych poprawek. Gdyby\u015bmy w\u00f3wczas stosowali Test-Driven Development, uda\u0142oby si\u0119 unikn\u0105\u0107 wielu frustracji zwi\u0105zanych z nieko\u0144cz\u0105cymi si\u0119 poprawkami. Jak wi\u0119c dzia\u0142aj\u0105 TDD?<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"schemat-ideowy-test-driven-development\">Schemat ideowy Test-Driven Development<\/h2>\n\n\n\n<p>Schemat ideowy Test-Driven Development (Red \u2013 Green \u2013 Refactor) wydaje si\u0119 wskazywa\u0107 na co\u015b bardzo prostego. Przyjrzyjmy si\u0119 jego poszczeg\u00f3lnym elementom.<\/p>\n\n\n\n<div style=\"height:34px\" aria-hidden=\"true\" class=\"wp-block-spacer\"><\/div>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/nearshore-it.eu\/wp-content\/uploads\/2024\/09\/jpro_refactoring.png\" alt=\"TDD cykl Red Green Refactor\" class=\"wp-image-22728\" title=\"\"><\/figure>\n\n\n\n<div style=\"height:34px\" aria-hidden=\"true\" class=\"wp-block-spacer\"><\/div>\n\n\n\n<p><strong>Red<\/strong>&nbsp;\u2013 to&nbsp;nic innego jak etap pisania test\u00f3w jednostkowych dla funkcjonalno\u015bci, kt\u00f3re uruchomione na&nbsp;aplikacji bez&nbsp;zaimplementowanego rozwi\u0105zania, si\u0142\u0105 rzeczy wygeneruj\u0105 raport o&nbsp;b\u0142\u0119dach, wskazuj\u0105cy w&nbsp;najlepszym razie na&nbsp;niepoprawne dzia\u0142anie aplikacji w&nbsp;tym obszarze (czyli jej brak). W&nbsp;wi\u0119kszo\u015bci wsp\u00f3\u0142czesnych narz\u0119dzi programistycznych do&nbsp;pisania kodu raport taki b\u0119dzie zabarwiony charakterystycznym kolorem czerwonym. Ten etap jest bardzo istotny. W\u0142a\u015bnie teraz developer dokonuje rozpoznania problemu, nad&nbsp;kt\u00f3rego&nbsp;rozwi\u0105zaniem pracuje, analizuj\u0105c dotychczasowy kod opisuj\u0105cy ten obszar (je\u017celi tylko&nbsp;taki istnieje). To&nbsp;r\u00f3wnie\u017c na&nbsp;tym etapie spoczywa\u0107 b\u0119dzie na&nbsp;jego barkach najwi\u0119kszy ci\u0119\u017car podczas implementacji nowej funkcjonalno\u015bci.<\/p>\n\n\n\n<p><strong>Green<\/strong>&nbsp;\u2013 to&nbsp;kolejny etap, w&nbsp;kt\u00f3rym&nbsp;czerwie\u0144 z&nbsp;kolejnych raport\u00f3w po&nbsp;uruchamianiu test\u00f3w jednostkowych b\u0119dzie w&nbsp;spos\u00f3b progresywny przechodzi\u0107 do&nbsp;barwy zielonej. Przej\u015bcie test\u00f3w b\u0119dzie sygnalizowane przez&nbsp;IDE (<em>Integrated Development Environment<\/em>). To&nbsp;na&nbsp;tym etapie dokonywa\u0107 si\u0119 b\u0119dzie w\u0142a\u015bciwa implementacja nowej funkcjonalno\u015bci.<\/p>\n\n\n\n<p><strong>Refactor<\/strong>&nbsp;\u2013 na&nbsp;tym etapie wprowadzamy poprawki do&nbsp;nowo zaimplementowanych funkcjonalno\u015bci. Mo\u017cliwie uwsp\u00f3lniamy zastosowane r\u00f3wnie\u017c w&nbsp;innych miejscach podobne rozwi\u0105zania. Dla w\u0142a\u015bciwej implementacji poprawiamy czysto\u015b\u0107 napisanego kodu i&nbsp;przygotowanych przypadk\u00f3w testowych. Ta faza nie&nbsp;oznacza ko\u0144ca test\u00f3w, gdy\u017c&nbsp;po&nbsp;kolejnych modyfikacjach kodu cykl Red \u2013 Green \u2013 Refactor powtarza si\u0119.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"test-driven-development-czy-mozna-zaczac-od-fazy-green\">Test-Driven Development \u2013 czy mo\u017cna zacz\u0105\u0107 od fazy Green?<\/h3>\n\n\n\n<p>Mo\u017cemy oczywi\u015bcie osi\u0105gn\u0105\u0107 podobne rezultaty, zaczynaj\u0105c prac\u0119 od&nbsp;fazy Green, poprzez Red, a\u017c do&nbsp;Refactoringu. Jako \u017ce&nbsp;jest ca\u0142kiem spora szansa na&nbsp;zaimplementowanie aplikacji, zanim jeszcze przygotujemy do&nbsp;niej zestawy test\u00f3w jednostkowych, taka \u015bcie\u017cka wydaje si\u0119 nawet kusz\u0105ca. Jest jednak haczyk w&nbsp;takim podej\u015bciu.&nbsp;<strong>W&nbsp;ferworze walki z&nbsp;kolejnymi funkcjonalno\u015bciami mo\u017cemy zacz\u0105\u0107 przywi\u0105zywa\u0107 coraz mniejsz\u0105 uwag\u0119 do&nbsp;jako\u015bci naszych scenariuszy testowych.<\/strong>&nbsp;Nie&nbsp;twierdz\u0119 co prawda, \u017ce&nbsp;tak&nbsp;musi by\u0107, ale&nbsp;pr\u0119dzej czy&nbsp;p\u00f3\u017aniej nasz kod testuj\u0105cy mo\u017ce nie&nbsp;pokrywa\u0107 mo\u017cliwych scenariuszy lub nawet sta\u0107 si\u0119 bezwarto\u015bciowy. Ro\u015bnie w\u00f3wczas ryzyko wyst\u0105pienia powa\u017cnych b\u0142\u0119d\u00f3w na&nbsp;\u015brodowisku produkcyjnym \u2013 b\u0142\u0119d\u00f3w trudnych do&nbsp;naprawy i&nbsp;najcz\u0119\u015bciej w&nbsp;rzadko u\u017cywanych obszarach. To&nbsp;cz\u0119sto skutkuje sporymi wydatkami po&nbsp;stronie klienta zwi\u0105zanymi z&nbsp;napraw\u0105 b\u0142\u0119d\u00f3w.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"tdd-test-zalety-rozpoczynania-od-fazy-red\">TDD test \u2013 zalety rozpoczynania od fazy Red<\/h3>\n\n\n\n<p>Du\u017co si\u0119 m\u00f3wi o&nbsp;tym, \u017ce&nbsp;rozpoczynaj\u0105c cykl realizacji funkcjonalno\u015bci od&nbsp;przygotowania test\u00f3w jednostkowych, b\u0119dziemy potrzebowa\u0107 wi\u0119cej czasu na zadanie ni\u017c w&nbsp;sytuacji, gdy&nbsp;prace zaczniemy od&nbsp;implementacji. To&nbsp;mo\u017ce by\u0107 prawd\u0105, gdy&nbsp;programista zaczyna prac\u0119 nad&nbsp;nowym projektem i&nbsp;wszystko musi przygotowa\u0107 od&nbsp;zera. W\u00f3wczas mo\u017ce pojawi\u0107 si\u0119 potrzeba utworzenia dodatkowych klas wspieraj\u0105cych tworzenie przypadk\u00f3w testowych lub wdro\u017cenia jednego z&nbsp;dost\u0119pnych template engine\u2019\u00f3w do&nbsp;generowania request\u00f3w albo&nbsp;event\u00f3w. W&nbsp;nieco p\u00f3\u017aniejszych okresach rozwoju aplikacji, je\u017celi pojawi\u0105 si\u0119 jakie\u015b r\u00f3\u017cnice, to&nbsp;raczej na&nbsp;marginalnie niskim poziomie.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"jak-minimalizowac-liczbe-testow\">Jak minimalizowa\u0107 liczb\u0119 test\u00f3w?<\/h2>\n\n\n\n<p>Czy&nbsp;nie&nbsp;powinni\u015bmy tworzy\u0107 scenariuszy testowych dla ka\u017cdej, nawet najmniejszej drobiny naszego kodu? Wiadomo, \u017ce&nbsp;najmniejsze nawet drobiny s\u0105 sk\u0142adowymi pewnych wi\u0119kszych struktur i&nbsp;zwykle jest szansa na&nbsp;to, by&nbsp;mo\u017cna je wsp\u00f3lnie opisa\u0107 przy pomocy kilku rozs\u0105dnych scenariuszy przypadk\u00f3w brzegowych. Oczywi\u015bcie zdarzaj\u0105 si\u0119 takie obszary, jak na&nbsp;przyk\u0142ad walidatory czy&nbsp;kalkulatory, kt\u00f3rych&nbsp;cz\u0119sto nie&nbsp;spos\u00f3b zbada\u0107 i&nbsp;pokry\u0107 niewielk\u0105 ilo\u015bci\u0105 przekrojowych test\u00f3w. Chcia\u0142bym jednak podpowiedzie\u0107, jak minimalizowa\u0107 liczb\u0119 test\u00f3w, oszcz\u0119dzaj\u0105c tym samym czas i&nbsp;wykorzystuj\u0105c na&nbsp;co dzie\u0144 pe\u0142en potencja\u0142 TDD.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"testy-a-nieistniejace-przypadki-biznesowe\">Testy a nieistniej\u0105ce przypadki biznesowe<\/h3>\n\n\n\n<p>Ciekawym zagadnieniem jest pokrywanie testami nieistniej\u0105cych przypadk\u00f3w biznesowych. Dylematu tego nie napotkamy zwykle podczas tworzenia test\u00f3w dla walidator\u00f3w czy filtr\u00f3w, ale&nbsp;podczas przypadku takiego jak pisanie test\u00f3w z&nbsp;dzia\u0142ania tworzonej funkcjonalno\u015bci \u2013 ju\u017c tak.&nbsp;<strong>Chodzi zwykle o&nbsp;sytuacje, kt\u00f3re z&nbsp;takich czy&nbsp;innych powod\u00f3w nie&nbsp;zadziej\u0105 si\u0119 nigdy \u2013 jak wtedy, gdy&nbsp;nasza funkcjonalno\u015b\u0107 zale\u017ce\u0107 b\u0119dzie od&nbsp;danych ze&nbsp;\u015bci\u015ble okre\u015blonych i&nbsp;zdefiniowanych zbior\u00f3w<\/strong><strong>.<\/strong> Przyk\u0142adem mo\u017ce by\u0107 wyb\u00f3r kodu kraju wyst\u0105pienia szkody komunikacyjnej, gdy&nbsp;wykorzystujemy przeznaczon\u0105 funkcjonalno\u015b\u0107 do&nbsp;ich rejestracji. Maj\u0105c \u015bwiadomo\u015b\u0107, \u017ce&nbsp;u\u017cytkownik b\u0119dzie m\u00f3g\u0142 wskaza\u0107 jeden ze&nbsp;zdefiniowanych w&nbsp;bazie kod\u00f3w, wiemy, \u017ce&nbsp;nie&nbsp;b\u0119dzie mia\u0142 on opcji wyboru innego lub nieistniej\u0105cego kodu podczas rzeczywistej pracy aplikacji. Czy&nbsp;w&nbsp;takim razie ma sens testowanie tego, jak zareaguje aplikacja, gdy&nbsp;u\u017cytkownik wybierze kod kraju \u201eXXL\u201d, je\u017celi do&nbsp;dyspozycji zawsze b\u0119dzie mia\u0142 np.: tylko&nbsp;\u201ePL\u201d i&nbsp;\u201eDE\u201d?<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"stosuj-parametryzacje\">Stosuj parametryzacj\u0119<\/h2>\n\n\n\n<p>Kolejnym przyk\u0142adem minimalizacji liczby test\u00f3w z&nbsp;zachowaniem pokrycia jest parametryzacja, czyli technika konsolidowania scenariuszy, do&nbsp;kt\u00f3rej&nbsp;u\u017cywania chcia\u0142bym zach\u0119ci\u0107. Mimo \u017ce&nbsp;w&nbsp;tym podej\u015bciu nadal tworzymy tyle samo przypadk\u00f3w testowych, to&nbsp;jednak samego kodu testowego jest mniej. Z&nbsp;racji wielo\u015bci warunk\u00f3w koniecznych do&nbsp;zbadania takie rozwi\u0105zanie sprawdzi\u0107 si\u0119 mo\u017ce podczas testowania klas walidator\u00f3w, kalkulator\u00f3w itp. Jego wad\u0105 mo\u017ce by\u0107 spadek czytelno\u015bci opis\u00f3w takich test\u00f3w zawartych w&nbsp;nazwach metod, co zwykle towarzyszy\u0107 mo\u017ce wszelkim aktom konsolidacyjnym. Nie&nbsp;b\u0119dzie to&nbsp;jednak \u017cadn\u0105 przeszkod\u0105 ani problemem, je\u015bli w&nbsp;naszym projekcie zdecydujemy si\u0119 na&nbsp;wykorzystanie wsp\u00f3\u0142czesnych narz\u0119dzi, jak Spock Framework, kt\u00f3ry&nbsp;dostarczy nam znacznych u\u0142atwie\u0144 podczas samego pisania asercji. U\u0142atwienia te otrzymamy stricte z&nbsp;j\u0119zyka Groovy, na&nbsp;kt\u00f3rym&nbsp;bazuje wspomniany framework. J\u0119zyk Groovy zapewnia wi\u0119ksz\u0105 przejrzysto\u015b\u0107 w&nbsp;kontek\u015bcie test\u00f3w i&nbsp;dokumentacji.&nbsp;<strong>W&nbsp;\u0142atwy spos\u00f3b uzyskamy nazwy scenariuszy, ale&nbsp;te\u017c mo\u017cliwo\u015b\u0107 dodania dodatkowych opis\u00f3w.<\/strong>&nbsp;Pozwoli to&nbsp;tak\u017ce zachowa\u0107 czyteln\u0105 form\u0119 przypadk\u00f3w testowych, zgodn\u0105 z&nbsp;\u201egiven, when, then\u201d. Na&nbsp;pewno pozwoli to&nbsp;lepiej udokumentowa\u0107 nasze funkcjonalno\u015bci.<\/p>\n\n\n\n<p>Mo\u017cemy niekiedy trafi\u0107 na&nbsp;zwolennik\u00f3w tworzenia osobnych przypadk\u00f3w per scenariusz, czyli niekonsolidowania. W\u00f3wczas jednak wracamy do&nbsp;tematu przysz\u0142ego utrzymania wszystkich test\u00f3w, gdy&nbsp;nasza aplikacja b\u0119dzie si\u0119 rozwija\u0107. Zawsze jest co\u015b za&nbsp;co\u015b\u2026 Zwykle najrozs\u0105dniej jest jednak zachowa\u0107 umiar.&nbsp;<strong>Gdy&nbsp;w&nbsp;czasie poszukiwania z\u0142otego \u015brodka pojawi si\u0119 temat rozbudowany i&nbsp;skomplikowany, to&nbsp;pomimo wielu podobie\u0144stw w&nbsp;przypadkach testowych moim zdaniem warto rozpisa\u0107 je z&nbsp;osobna, jeden po&nbsp;drugim.<\/strong>&nbsp;Kategoryczno\u015b\u0107 podej\u015bcia mo\u017ce doprowadzi\u0107 do&nbsp;zagubienia u\u017cyteczno\u015bci, jak\u0105 powinny wnie\u015b\u0107 testy jednostkowe (unit tests) do&nbsp;naszej codziennej pracy. Skupiaj\u0105c si\u0119 zbytnio na&nbsp;formie, mo\u017cemy zatraci\u0107 rozumienie funkcji scenariuszy testowych.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"zadbaj-o-czytelnosc-testow-jednostkowych\">Zadbaj o czytelno\u015b\u0107 test\u00f3w jednostkowych<\/h2>\n\n\n\n<p>Tak&nbsp;samo wa\u017cne jest, by&nbsp;skupiaj\u0105c si\u0119 na&nbsp;funkcji samego przetestowania analizowanych obszar\u00f3w, nie&nbsp;zatraci\u0107 formy.&nbsp;<strong>Estetyka i&nbsp;opisowo\u015b\u0107 w&nbsp;nazwach scenariuszy, u\u017cytych nazwach metod czy&nbsp;zmiennych dokumentuje nam obszary funkcjonalno\u015bci i&nbsp;pozwala wykorzystywa\u0107 test w&nbsp;spos\u00f3b \u015bwiadomy i&nbsp;zrozumia\u0142y.<\/strong>&nbsp;Zaryzykuj\u0119 stwierdzeniem, \u017ce&nbsp;miar\u0105 u\u017cyteczno\u015bci testu jednostkowego b\u0119dzie zar\u00f3wno rozs\u0105dne pokrycie testem badanego obszaru, jak i&nbsp;czytelno\u015b\u0107 jego implementacji. Takie podej\u015bcie uchroni nas przed&nbsp;sytuacj\u0105, kt\u00f3rej&nbsp;wielu mog\u0142o do\u015bwiadczy\u0107, a&nbsp;mianowicie kiedy po&nbsp;d\u0142u\u017cszym czasie trudno jest zacz\u0105\u0107 prac\u0119 nad&nbsp;rozwojem dawno zaimplementowanego obszaru. Bez&nbsp;starannie napisanych, czytelnych test\u00f3w nasza praca b\u0119dzie prawdziw\u0105 drog\u0105 przez&nbsp;m\u0119k\u0119.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"korzysci-z-tdd-dla-klienta-i-developera\">Korzy\u015bci z TDD dla klienta i developera<\/h2>\n\n\n\n<p><strong>TDD dla developera to&nbsp;przede wszystkim:<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>wy\u017cszy komfort pracy \u2013 r\u00f3wnie\u017c pracy z&nbsp;istniej\u0105cym kodem dzi\u0119ki mniejszej liczbie b\u0142\u0119d\u00f3w,<\/li>\n\n\n\n<li>dokumentacja funkcjonalno\u015bci na&nbsp;wysokim poziomie,<\/li>\n\n\n\n<li>lepsza wiedza biznesowa, a&nbsp;tym samym lepsza znajomo\u015b\u0107 produktu,<\/li>\n\n\n\n<li>wi\u0119ksza szansa na&nbsp;czysty kod,<\/li>\n\n\n\n<li>\u0142atwiejszy start pracy w&nbsp;projekcie<\/li>\n\n\n\n<li>redukcja stresu i&nbsp;mniej presji w&nbsp;pracy,<\/li>\n<\/ul>\n\n\n\n<p><strong>TDD dla klienta to:<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>wy\u017cszy poziom pewno\u015bci co do&nbsp;poprawno\u015bci dzia\u0142ania aplikacji i&nbsp;mniej b\u0142\u0119d\u00f3w,<\/li>\n\n\n\n<li>mo\u017cliwo\u015b\u0107 przewidywania koszt\u00f3w utrzymania aplikacji oraz&nbsp;wprowadzania modyfikacji do&nbsp;ju\u017c istniej\u0105cych rozwi\u0105za\u0144,<\/li>\n\n\n\n<li>oszcz\u0119dno\u015bci na&nbsp;wdra\u017caniu nowych programist\u00f3w do&nbsp;pracy przy projekcie,<\/li>\n\n\n\n<li>szybsze lokalizowanie i&nbsp;naprawianie zaistnia\u0142ych b\u0142\u0119d\u00f3w,<\/li>\n\n\n\n<li>wi\u0119ksza szansa na&nbsp;interesuj\u0105ce sugestie od&nbsp;developera co do&nbsp;wprowadzanych rozwi\u0105za\u0144, dzi\u0119ki lepszej znajomo\u015bci obecnych funkcjonalno\u015bci,<\/li>\n\n\n\n<li>TDD oznacza lepszy kod, a&nbsp;wi\u0119c&nbsp;i&nbsp;lepsz\u0105 aplikacj\u0119.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"podsumowanie\">Podsumowanie<\/h2>\n\n\n\n<p>Mam nadziej\u0119, \u017ce&nbsp;uda\u0142o mi si\u0119 przekaza\u0107, co wnosi TDD do&nbsp;codziennej pracy i&nbsp;jakie mog\u0105 by\u0107 konsekwencje niestosowania go w&nbsp;praktyce. Wspomniane przeze mnie zasady sprzyjaj\u0105ce minimalizacji test\u00f3w: parametryzacja, minimalizacja ilo\u015bci, pomijanie nieistniej\u0105cych przypadk\u00f3w biznesowych w&nbsp;scenariuszach oraz&nbsp;czytelno\u015b\u0107 kodu testowego nie&nbsp;wynikaj\u0105 bezpo\u015brednio z&nbsp;definicji TDD. Nie&nbsp;spos\u00f3b jednak w&nbsp;praktyce osi\u0105gn\u0105\u0107 prawdziwego rozwoju za&nbsp;pomoc\u0105 test\u00f3w bez&nbsp;rozs\u0105dnego ich przestrzegania. Wierz\u0119, \u017ce&nbsp;uda\u0142o mi si\u0119 zaprezentowa\u0107, czym jest metodyka Test-Driven Development i&nbsp;jak wielk\u0105 warto\u015b\u0107 niesie ze&nbsp;sob\u0105 bazuj\u0105ca na&nbsp;niej produkcja dedykowanego oprogramowania.<\/p>\n\n\n\n<p><strong>Przeczytaj tak\u017ce:\u00a0<a href=\"https:\/\/nearshore-it.eu\/pl\/artykuly\/clean-architecture\/\">Clean architecture<\/a><\/strong><\/p>\n\n\n\n<p><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Z biznesowego punktu widzenia tym, czego oczekuje klient, jest dzia\u0142aj\u0105ca aplikacja. Nic wi\u0119c dziwnego, \u017ce dla niego testy jednostkowe s\u0105 zwykle jedynie dodatkiem, z kt\u00f3rego najch\u0119tniej by zrezygnowa\u0142. I rzeczywi\u015bcie \u2013 do niedawna nie przyk\u0142adano tak wielkiej uwagi do pisania test\u00f3w jednostkowych i w takiej konwencji powsta\u0142o co najmniej kilka powa\u017cnych aplikacji, o kt\u00f3rych wiem, a w\u015br\u00f3d nich programy do gospodarowania magazynami, wspieraj\u0105ce dzia\u0142anie sklep\u00f3w, instytucji finansowych i bank\u00f3w. Jednak na przestrzeni ostatnich 15 lat obserwujemy na szcz\u0119\u015bcie ewolucj\u0119 sposobu postrzegania test\u00f3w, a dawne podej\u015bcie staje si\u0119 powoli \u201eprehistori\u0105 developmentu\u201d. Przenie\u015bmy si\u0119 wi\u0119c do wsp\u00f3\u0142czesno\u015bci i przyjrzyjmy stosowaniu Test-Driven Development, czyli podej\u015bciu, kt\u00f3re jest \u2018state of the art\u2019 wsp\u00f3\u0142czesnych test\u00f3w oprogramowania.<\/p>\n<p>Z tego artyku\u0142u dowiesz si\u0119:<\/p>\n<ul>\n<li>Czym jest Test-Driven Development,<\/li>\n<li>Czym mo\u017ce skutkowa\u0107 brak TDD \u2013 case study,<\/li>\n<li>Jaki jest schemat ideowy Test-Driven Development,<\/li>\n<li>Jak minimalizowa\u0107 liczb\u0119 test\u00f3w,<\/li>\n<li>Jak zadba\u0107 o&nbsp;czytelno\u015b\u0107 test\u00f3w jednostkowych,<\/li>\n<li>Jakie s\u0105 korzy\u015bci z TDD dla klienta i developera.<\/li>\n<\/ul>\n","protected":false},"author":121,"featured_media":31635,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"iawp_total_views":40,"footnotes":""},"categories":[1,582],"tags":[],"offering":[522],"class_list":["post-31630","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-artykuly","category-technologie","offering-tech-blog"],"acf":[],"_links":{"self":[{"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/posts\/31630","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/users\/121"}],"replies":[{"embeddable":true,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/comments?post=31630"}],"version-history":[{"count":4,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/posts\/31630\/revisions"}],"predecessor-version":[{"id":33219,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/posts\/31630\/revisions\/33219"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/media\/31635"}],"wp:attachment":[{"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/media?parent=31630"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/categories?post=31630"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/tags?post=31630"},{"taxonomy":"offering","embeddable":true,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/offering?post=31630"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}