TDD, BDD, DDD… o co w tych skrótach chodzi?

Pamiętam jak ucząc się programowania usłyszałem o TDD, czyli Test-Driven Development. Wydawało mi się to bardzo ciekawym podejściem w programowaniu. Parę miesięcy później usłyszałem pytanie o TDD na rozmowie kwalifikacyjnej i zadowolony szybko na nie odpowiedziałem. Tylko potem padło pytanie o BDD, o którym nie wiedziałem nic. Później jeszcze dowiedziałem się, że jest DDD, FDD i pewnie z czasem dojdzie jeszcze kilka kolejnych XDD. Co więc znaczą te wszystkie skróty i czym się od siebie różnią dane podejścia?

TDD, czyli Test-Driven Development.

To podejście w tworzeniu oprogramowania, które na samym początku zakłada napisanie testów, a dopiero później właściwego kodu spełniającego dane założenia. W ostatnim kroku TDD programista dokonuje refaktoryzacji kodu. Takie podejście daje gwarancję, że stworzymy oprogramowanie spełniające przyjęte na początku założenia (uwzględnione w testach). Odpalając test przed implementacją kodu możemy upewnić się, że wszystkie testy zostaną oblane, czyli nie przejdą i zaświecą się nam na czerwono. Dlatego ta pierwsza faza nazywana jest „czerwoną”. W drugiej, po napisaniu kodu, testy powinny przejść już bez problemów i faza ta zwana jest „zieloną”. Ostatnia faza to prostu z ang. refactoring.

BDD, czyli Behavior-Driven Development.

Kod, który tworzysz bardzo często odzwierciedla rzeczywiste zachowania, procesy, rzeczy, osoby czy obiekty. Takie programowanie wydaje się często naturalne i prostsze, zarówno dla piszącego, jak i czytającego programisty. I właśnie do odzwierciedlania rzeczywistych zachowań zmierza technika BDD. Z jednej strony Behavior-Driven Development rozwija technikę TDD i również zakłada tworzenie oprogramowania w oparciu o testy, ale też idzie o krok dalej. Zarówno kod, jak i testy powinny odpowiadać rzeczywistym zachowaniom. Być może spotkaliście się z BDD całkiem nieświadomie stosując w testach wzór Given-When-Then, jako szkielet testu. Takie podejście pomaga łączyć osoby z tzw. biznesu, czyli nietechniczne, z programistami. Dostarczając konkretne scenariusze, programista wie nie tylko co jego kod ma zrobić, ale również jak można go napisać by był czytelny i zrozumiały, a testy sprawdziły wszystkie możliwe zachowania. Co ciekawe oprócz nawiązania do TDD, ta technika łączy się również z kolejnym pojęciem, czyli DDD. To tylko krótkie przedstawienie tematu BDD, bo więcej znajdziecie np. na blogu firmy JCommerce.

DDD, czyli Domain-Driven Development.

Tak jak wspomniałem, BDD bliskie jest DDD, czyli podejściu opartemu o dziedzinę. Nie sposób w jednym akapicie opisać całą złożoność procesu tworzenia oprogramowania według zasad DDD, gdyż można o tym temacie znaleźć książki, jednak spróbuję w skrócie nakreślić główne założenia. W Domain-Driven Development ważna jest domena, czy też dziedzina, której dotyczy projektowane oprogramowanie. To właśnie ścisła współpraca na linii programista-ekspert ma w założeniu stworzyć taki model dziedziny, który jest bliski temu jak dany problem rozumieją eksperci. Eksperci to w założeniu też użytkownicy danego programu. Dzięki temu program stworzony w DDD nie tyle będzie miał odpowiednie nazewnictwo klas czy metod, ale całe jego działanie, relacje, interfejs użytkownika będzie odpowiadał temu jak dany problem jest rozumiany i rozwiązywany przez ekspertów. Innymi słowy program oparty na stworzonym modelu ma bardziej odpowiadać zapotrzebowaniu użytkowników.

Inne …DD?

W swoim programistycznym życiu spotkałem się jeszcze z kilkoma pojęciami, niektórymi nawet o tych samych skrótach. Na przykład MDD może oznaczać Metadata-Driven Development lub Model-Data Development. Również dla skrótu BDD można znaleźć inne rozwinięcie Business-Driven Davelopment. Poza tymi rozpisanymi technikami polecam jeszcze uwadze FDD, czyli Feature-Driven Development. Celowo nie opisałem go tutaj, gdyż nie miałem za bardzo styczności z tym podejściem, a kompleksowy artykuł można znaleźć na Wikipedii.

Myślę, że szczególnie przed rozmową o pracę warto zapoznać się z tymi skrótami, a co do TDD, BDD i DDD to myślę, że przydadzą się w praktyce.

TDD, BDD, DDD… o co w tych skrótach chodzi?

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Przewiń do góry