Behavior driven development

Behavior driven development
Polecane artykuły
Ontologia Projektowanie systemów informatycznych Wzorce projektowe INVEST Drzewo decyzyjne UML Diagram procesu Business Process Modeling Notation Dokumentowanie wymagań klienta

Behavior Driven Development (BDD) – rodzaj zwinnego podejścia do wytwarzania oprogramowania rozwinięty przez dana Northa, a oparty na procesie Test Driven Development -TDD (C. Solís, X. Wang 2011, s.1). W metodzie tej testy akceptacyjne (acceptance tests) napisane są w języku naturalnym, czego celem jest powszechne zrozumienie pomiędzy poszczególnymi członkami zespołu projektowego. Mapowanie tak napisanych zdań jest początkiem cyklu projektowego (M. Soeken, R. Wille, R. Drechsler 2012, s. 1). W oparciu o praktyki TDD, zacząć należy od nieudanego testu akceptacyjnego przeprowadzonego przez klienta, opisującego zachowanie systemu z jego punktu widzenia. W BDD opisywane są one jako przykłady zrozumiałe dla każdego członka zespołu. Proces opisywania wykorzystywany jest do pozyskiwania informacji zwrotnej od interesariuszy w celu weryfikacji obranego kierunku działań, zanim zostaną one podjęte. Celem jest wytworzenie „powszechnego” (ubiquitous) języka, używanego do wymiany informacji na temat systemu, w tym jego opisu (M. Wynne, A. Hellesoy, S. Tooke 2017, s. 29).

Geneza Behavior Driven Development

TDD jest ewolucyjnym podejściem opierającym się na krótkich cyklach rozwoju oraz metodologiach zwinnych w pisaniu zautomatyzowanych testów poprzedzających zarówno tworzenie właściwego kodu, jak i jego przebudowę i ciągła integrację (S. Nelson-Smith 2013, s. 126). Typem TDD jest Acceptance Test Driven Development (ATDD). W wariancie tym, proces wytwarzania oprogramowania oparty jest na testach akceptacyjnych zawierających wymagania interesariuszy. Pomaga on deweloperom w przekładaniu owych wymagań na tzw. „testowe przypadki” (test cases) i weryfikacji funkcjonalności systemu. Dane wymaganie zostaje zaspokojone, jeżeli wszystkie powiązane testy, bądź kryteria są spełnione. Zarówno TDD, jak i ATDD nastręczają pewnych problemów. Wśród nich wyróżnia się przede wszystkim fakt, iż są one skupione raczej na weryfikacji aktualnego stanu systemu, niż na jego pożądanym zachowaniu. W obu wymienionych podejściach stosuje się również nieposiadający ścisłej struktury, język naturalny. Wykorzystuje się go do opisywania „przypadków”, a z powodu owego nieuporządkowania powoduje on trudności w ich zrozumieniu (M. Soeken, R. Wille, R. Drechsler 2012, s. 2).

BDD jest w swej istocie ewolucją obu powyższych podejść. Metoda ta skupia się przede wszystkim na wypracowaniu precyzyjnego opisu zachowania systemu docelowego, tak by mogły być zautomatyzowane. Testy w BDD są napisane w sposób przejrzysty i łatwy do zrozumienia ze względu na stosowanie „powszechnego” języka, będącego narzędziem interesariuszy, używanym do precyzyjnego opisu testów (C. Solís, X. Wang 2011, s.1).

Cechy Behavior Driven Development

1. „Powszechny” (ubiquitous) język Koncepcja ta jest centralną dla BDD, jest to język, którego struktura wywodzi się z określonego z góry modelu (M. Soeken, R. Wille, R. Drechsler 2012, s. 2). Zawiera wszystkie pojęcia, które będą użyte do definicji zachowania systemu. Język ten oparty jest o pewien model biznesowy. Umożliwia on płynną komunikację między klientami, a deweloperami (M. Wynne, A. Hellesoy, S. Tooke 2017, s. 29-30). Wykreowanie tego rodzaju języka jest szczególnie istotne ze względu na to, iż powinien on być stosowany w całym cyklu rozwoju oprogramowania. Zbiór pojęć, czy też słownik tworzony jest na samym początku projektu. Większość słownictwa powinna zostać przygotowana jeszcze w fazie analizy, jednakże można je poszerzać we wszystkich fazach rozwoju. W proces ten powinni być zaangażowani wszyscy specjaliści oraz deweloperzy, dla których stanie się on później narzędziem (C. Solís, X. Wang 2011, s.2).

2. Interaktywna dekompozycja procesu

Powszechnym jest problem porozumienia deweloperów i klientów. Projekt rozwoju oprogramowania musi dostarczyć pewnej trudnej do wyrażenia wartości biznesowej. Z tego powodu analiza w BDD rozpoczyna się od identyfikacji bardziej ścisłych i precyzyjnych w opisie oczekiwanych zachowań systemu. Są one pochodną wartości biznesowej, która ma zostać dostarczona. W wyniku dalszej analizy tworzy się tzw. „zbiory cech/fukncjonalności” (feature sets). Zbiory te uwidocznione są w „historiach/opowiadaniach użytkowników” (user stories) opisujących interakcję między użytkownikiem, a systemem. Muszą one dostarczyć odpowiedzi na trzy pytania:

• jaka jest rola użytkownika w danej historii?
• której funkcjonalności systemu chce użytkownik?
• jaką korzyść odnosi użytkownik, jeżeli system dostarcza daną funkcjonalność?

(C. Solís, X. Wang 2011, s.3)

3. Prosty opis tekstu przy użyciu szablonów historii użytkownika

BDD nie dopuszcza dowolności w formatowaniu opisu cech/funkcjonalności, historii użytkowników oraz scenariuszy. Istnieją określone szablony przygotowane w oparciu o wcześniej stworzony język. Zwykle wyglądają one następująco:

[Tytuł Historii] (jedno zdanie opisujące historię) Jako [Rola] Chcę [Funkcjonalność] Dzięki czemu uzyskam [Korzyść]

Scenariusz opisuje to, jak system zawierający daną funkcjonalność, powinien się zachowywać w określonym stanie lub w przypadku określonego zdarzenia. Scenariusze składają się z kontekstów, zdarzeń i akcji. Szablon dla scenariuszy wygląda, jak poniżej:

Scenariusz 1: [Tytuł Scenariusza] Dany/dana/dane [Stan/Sytuacja (kontekst)] I [Szerszy Kontekst]… Gdy [[[Zdarzenie]]] Wtedy [Efekt] I [Więcej Efektów]… Scenariusz 2 [Tytuł Scenariusza]…

(C. Solís, X. Wang 2011, s.3)

4. Zautomatyzowane testy akceptacyjne wraz z regułami mapowania

Charakterystyka zautomatyzowanych testów akceptacyjnych w BDD zaczerpnięta jest z ATDD. Sam test polega na określeniu zachowania systemu, umożliwiającym weryfikację w raczej interakcji, czy też zachowań poszczególnych obiektów, niż ich stanów. Deweloperzy rozpoczynają od przygotowanych uprzednio scenariuszy. Są one przetłumaczone na testy, będące czynnikiem determinującym implementację. Powinny one być odczytywane automatycznie, co oznacza, że kryteria akceptacji również muszą być importowane i analizowane w sposób automatyczny (M. Soeken, R. Wille, R. Drechsler 2012, s. 9). Reguły mapowania dostarczają standardów dla mapowania scenariuszy i przekładania ich na kod testowy. Jednym z podejść do powyższego jest następujący zestaw kroków:

• historia użytkownika przygotowana zostaje jako plik zawierający zestaw scenariuszy
• nazwa pliku jest mapowana dla określonej klasy historii użytkowników
• każdy krok scenariusza jest mapowany dla metody testowej, lokalizowanej za pomocą przypisu opisującego dany krok

(C. Solís, X. Wang 2011, s.4)

5. Czytelny, zorientowany na zachowanie (behawior) kod specyfikacji

Zgodnie z założeniami BDD, kod powinien być częścią dokumentacji systemu. Podejście takie odpowiada wartościom metodyk zwinnych. Kod musi być czytelny, a specyfikacja musi być jego częścią (C. Solís, X. Wang 2011, s.4).

6. ‘’Behavior Driven’’ w poszczególnych fazach

• w fazie inicjacji/planowania: zachowania muszą odpowiadać dostarczanej wartości biznesowej
• w fazie analizy: komponenty danej wartości dzielone są na cechy/funkcjonalności
• w fazie implementacji: integralną jej częścią są zautomatyzowane testy akceptacyjne

(C. Solís, X. Wang 2011, s.2)

Bibliografia

• Nelson-Smith S. (2013) ‘’Test-Driven Infrastructure with Chef’’, O’Reilly Media, Sebastopol, CA
• Soeken M., Wille R., Drechsler R. (2012) ‘’Assisted Behavior Driven Development Using Natural Language Processing’’, „Objects, Models, Components, Patterns, TOOLS”, Praga
• Solís C., Wang X. (2011) A Study of the Characteristics of Behaviour Driven Development, IEEE, Olulu
• Wynne M., Hellesoy A., Tooke S. (2017) ‘’The Cucumber Book: Behaviour-Driven Development for Testers and Developers’’, The Pragmatic Bookshelf, Raleigh, NC

Autor: Michał Gędziorowski