Programowanie

Moje małe DDD -> BDD to the resque.

Behavior Driven Development – dosyć niedawno nawet słyszałem, że to Test Driven Development Done Right 🙂 Idea stojąca za tym hasłem to testowanie jednostkowe nie poszczególnych elementów systemu takich jak moduły, klasy czy funkcje, a testowanie zachowań systemu. Ponieważ użycie tej metody produkcji oprogramowania ma nam dać w teorii większe skupienie na tym co system ma robić, a nie jak, wydaje mi się to idealnym rozwiązaniem pod projekt, który ma być tworzony za pomocą DDD 🙂

Samym BDD interesowałem się już dość dawno temu. O cucamberach i gherkinach słyszałem od kolegi Mateusza dobre 3 lata temu. W praktyce wdrożyłem ten sposób testowania za pomocą bibliotek Machine Specification w .NET. Ponieważ na początku nie wiedziałem z czym to się je i po co, to pewnie niektórzy koledzy w Sonecie czasem klną na to co widzą 🙂 Obecnie nadal używam mspec, na razie nie widziałem nic lepszego. W Ruby on Rails przepisałem wszystkie testy z Mini Test na rspec. W elixirze jeszcze nie wiem, ale na pewno BDD 🙂 Zdecydowanie przypadło mi do gustu.

A teraz -> co mnie to?

Skupić się na zachowaniach, a nie na modułach, klasach czy funkcjach. Po co to w ogóle ktoś wymyślił? Wydaje mi się, że dokładnie po to, po co wymyślono DDD. Dlatego, że mamy problemy z komunikacją. Jak najlepiej przekazać komuś instrukcję, czy nasze wyobrażenie, dotyczące kawałka programu? Najlepiej napisać mu kilka testów jednostkowych! Nie raz stosowane, świetnie się sprawdza – polecam. Ale jak ktoś nie jest programistą i nie potrafi określić jakie maja być obiekty czy funkcje? On(a) sobie nie wyobraża jak ma wyglądać program, ale osoba owa DOSKONALE (czyli lepiej niż my) wie co ma się stać w zadanym momencie przetwarzania. Ta osoba myśli językiem biznesowym, jednym słowem takim:

Kiedy wchodzę na tworzoną stronę internetową,

Jeśli zaznaczę, że jestem kobietą,

Powinno przekierować mnie na stronę klata_herosa.pl,

Na tej stronie w tle pojawią się nadzy mężczyźni,

Na tej stronie wszystkie napisy będą się odnosiły do płci żeńskiej,

Na tej stronie nie pojawią się żadne reklamy z gołymi kobietami,

Bo kto powiedział, że tylko mężczyźni oglądają różne pink, red i inne tuby? To powyżej to zdecydowanie nie jest test jednostkowy. To test typowy dla DSL (Domain Specific Language, a w linku dobry autor 🙂 ) w którym używamy pojęć specyficznych dla danej domeny. Również w DDD jest opisane, że należy zdecydować się na wspólny z biznesem język i musi to być język specjalistyczny dla danej dziedziny w której problemy przyszło nam rozwiązywać.

Jak ja taki test napisałbym w mspec (piszę z palca, przepraszam, ale artykuły tworzę na macu 🙂 ):

Nie skupiając się szczególnie nad techniką użycia Session itd. można ogólnie przyjąć, że napisałem właśnie testy integracyjne. Generalnie używając kilku różnych klas i obiektów (a więc nie są to testy jednostkowe) spełniłem wymagania biznesu. Po uruchomieniu tego testu biznes jest pewny, że kobieta oglądająca pewno wybitnie interesującą stronę, pozostanie na niej chwilę dłużej zadowolona, może nawet wyda kilka złoty na jakieś gadżety.

W ten sposób również zaczynam rozmawiać z biznesem jego językiem. To bardzo, bardzo, bardzo, bardzo… (tu wpisz ile razy to dla Ciebie naprawdę)… ważne. Kiedyś przeczytałem, że firmy tworzą oprogramowanie, które jest odbiciem ich procesów i komunikacji biznesowej. Zadbajmy o tą komunikację szczególnie mocno.

A dlaczego czasem nie?

BDD nie nadaje się do wszystkiego. Jednym z podstawowych zadań do których się nie nadaje jest sprawdzanie wielu przypadków tej samej instancji, czy nawet testowanie parametrów wejściowych funkcji. Nie za dobrze widziane są też testy min max i tym podobne. Za pomocą BDD opisuję tylko i wyłącznie zachowania, a dodatkowe testy dotyczące kodu i jego działania mam w nUnit.

W BDD każdy test jest zapisany za pomocą It, a jest grupowany w klasie. Po wykonaniu zestawu powyższych testów otrzymamy wynik:

Oznacza to, że przyrost przypadków testowych dla różnych kontekstów to znaczny przyrost ilości klas z Testami. To akurat nie jest problemem, bo przechowuję je w osobnym projekcie. Czasem tylko okazuje się, że mam więcej i bardziej przypadków testowych niż kodu który je spełnia.

Jest też jakaś tendencja do pisania should w nazwie testu. Czyli “It should_do_something…”. Osobiście jestem za minimalizacją, a więc usuwam co się da, byle tylko pozostać jako-tako czytelnym.

Staram się dosyć długo polegać tylko na testach behavioralnych (co mam nadzieję uda się w obu projektach – F#-powym i elixir-owym), a testy jednostkowe dodawać tylko wtedy, gdy kod staje się zbyt skomplikowany, a nie mogę (jeszcze) go zrefaktorować.

W kolejnych wpisach postaram się pokazać moje techniki pisania testów i odpowiadającego im kodu, oraz, jeśli się uda, ustawić Sonara pod te projekty. Trzymajcie się mocno, a ja postaram się znaleźć troszkę czasu na to jeszcze w tym miesiącu 🙂

3 thoughts on “Moje małe DDD -> BDD to the resque.”

  1. Pingback: dotnetomaniak.pl
  2. “BDD nie nadaje się do wszystkiego”… A próbowałeś SpecFlow? Tam możesz tworzyć szablony scenariuszy, dzięki czemu możesz sprawdzać wiele przypadków w jednym scenariuszu. Poza tym składnia (gherkin) scenariuszy bardziej odpowiada językowi naturalnego, a nawet można ją dostosować do języka np. polskiego, by ułatwić weryfikację założeń nietechnicznemu klientowi (użytkownikowi). Dobrze się z tym pracuje. Polecam.

    1. Tak, patrzyłem i oglądałem. Generalnie fajne, ale jednak w pracy z klientem. Jeśli pracuję “dla siebie” i testy piszę “dla siebie” pod specyfikację którą dał mi klient wolę mspec – szybko sprawnie i w konwencji. Podoba mi się. Natomiast jak najbardziej zgadzam się – gherkin do kontaktów z klientem jest cool.

Leave a Reply

Your email address will not be published. Required fields are marked *