Behavior Driven Development – BDD. Jak pisać wymagania zrozumiałe dla wszystkich

Skuteczna komunikacja między zespołem deweloperskim, a interesariuszami oraz rozumienie potrzeb obu stron, to kluczowy element wytwarzania i rozwoju oprogramowania. Znalezienie wspólnego języka, który zapewni spójny opis funkcjonalności może znacząco poprawić jakość wytwarzanego oprogramowania.

Behavior Driven Development to zbiór praktyk, dzięki którym opis funkcjonalności będzie w pełni zrozumiały dla biznesu i zapewni poziom szczegółowość potrzeby programistom do implementacji. Dodatkowo specyfikacja zbudowana wg. BDD stanie się gotowym, w pełni automatycznym zestawem testów akceptacyjnych i dokumentacją niskiego poziomu.

Techniki BDD (dosł. programowanie sterowane zachowaniami) bazują na praktykach Agile i Lean, w szczególności technikach programowania sterowanego testami (TDD) oraz projektowania domenowego (Domain Driven Design — DDD). 

W BDD olbrzymią rolę odgrywa współpraca — zarówno między użytkownikami a zespołem projektowym, jak i wewnątrz samego zespołu. Analitycy biznesowi, programiści i testerzy podczas definiowania i specyfikowania cech funkcjonalnych współpracują z użytkownikami końcowymi, a członkowie zespołu czerpią pomysły ze swoich indywidualnych doświadczeń oraz know-how.

Specyfiką BDD jest język naturalny, którego struktura wywodzi się z określonego z góry modelu. Zawiera wszystkie pojęcia, które będą użyte do definicji zachowania systemu. Umożliwia on płynną komunikację między klientami, a deweloperami. 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 Gherkin.

Krótszy proces dostarczania

Kompleksowe testy sterowane zachowaniem przyczyniają się także do skrócenia procesu dostarczania nowych wersji aplikacji (CD). Zespół testerów nie musi już marnować czasu na długotrwałe ręczne testowanie elementów aplikacji przed każdym wydanie. Testerzy mogą skupić się na bardziej wyszukanych testach manualnych i badawczych (np. testach użyteczności).

Unikanie marnotrawstwa

Bardzo często zdarza się, że zespoły marnują swój czas na implementację funkcjonalności, które biznes wcale nie potrzebuje i nigdy nie będzie ich używał. Stosowanie praktyk BDD pozwala uniknąć marnotrawstwa czasu i wysiłków, ponieważ pomaga zespołom skoncentrować się na cechach funkcjonalnych, które są dostosowane do celów biznesowych. Określenie dokładnych scenariuszy zachowania pomaga w określeniu, które elementy są istotne dla danej implementacji, a które są zupełnie zbędne i nie warto się nimi zajmować.

Jak wygląda proces w BDD?

Proces BDD świetnie sprawdza się w zwinnych metodykach wytrzymywania oprogramowania.

1. Jacek przychodzi do Krzyśka – analityka biznesowego i opowiada o funkcjonalnościach, które chciałby wdrożyć w aplikacji. Aby zmniejszyć ryzyko nieporozumień posługują się konkretnym przykładami tego, co dana funkcja ma realizować.
2. Krzysiek – nasz analityk biznesowy przed rozpoczęciem pracy nad daną funkcjonalnością spotyka się z zespołem deweloperskim (programiści, testerzy). Wspólnie dyskutują na temat kluczowych przykładów i przekształcają je na zestaw wymagań (scenariuszy) zapisanych w formie specyficznego języka Gherkin dla BDD. Język ten jest zrozumiały dla wszystkich członków zespołu, w tym także interesariuszy.
3. Programista używa narzędzi BDD do przekształcenia zapisanych wcześniej scenariuszy na zestaw testów automatycznych, które są uruchamiane i weryfikują obiektywnie na jaki etapie jest dana implementacja.
4. Tester używa zapisanych scenariuszy jako punkt wyjścia do bardziej wyszukanych testów manualnych, które ciężko zautomatyzować.
5. Testy automatyczne i przygotowane scenariusze spełniają funkcję niskopoziomowych dokumentacji technicznych i dostarczają realne przykłady działania aplikacji.

Cel biznesowy

Według BDD opis nowej funkcjonalności powinien rozpoczynać się od zdefiniowania historyjki użytkownika, która opisuje cel biznesowy, rolę i to co dana funkcja ma wykonywać. Ważne, aby wszyscy członkowie zespołu rozumieli co dany projekt ma realizować. Cele biznesowe muszą być przekazane zespołowi deweloperskiemu, aby znał dokładny kontekst tego co jest do zaimplementowania.

Opis każdej nowej funkcjonalności powinien rozpoczynać się od stwierdzeń:

Specyfikacja przez przykład

Kolejnym krokiem jest dodanie scenariusza (przypadków użycia), który wyjaśni w jaki sposób ma działać dana implementacja, ale także będzie kryterium dla testów akceptacyjnych. Wykorzystanie przykładów do określenia oczekiwanych zachowań systemu jest kluczową częścią technik BDD. Naturalny porządek scenariusza to Zakładając… Gdy… Wtedy (ang. Given… When… Then):

Pełny opis funkcji z historyjką i przypadkami użycia oraz testami akceptacyjnymi:

Jak widać na przykładzie, stosując odpowiedni zapis otrzymujemy pełnowartościowy opis funkcjonalności, który zawiera precyzyjne informacje i przykłady. Można go jeszcze rozszerzyć o dane w formie tabeli, które będą obrazowały zmianę wartości w konkretnych przypadkach. Na tej podstawie zespół programistów jest już w stanie zaimplementować daną funkcjonalność.

Narzędzia wspomagające proces BDD

Narzędzia wspomagające BDD są zależne od języka programowania, w którym budujemy nasze rozwiązania. W przypadku PHP może być to framework Behat, a w przypadku Javy np. JBehave. Narzędzi jest całkiem sporo i wybór odpowiedniego frameworka zależy już od preferencji zespołu projektowego.

Przykładowy plik .feature z frameworka Behat:

Feature: weather indicator
    In order to get weather information
    As a user
    I want to get a human readable version of xml weather forcast

    Scenario:
        Given xml input "<some>strange</parsing error>"
        When I run my application
        Then I should get an exception with message "service currently not available"

    Scenario:
        Given xml input "<weather><cloud>0</cloud><temperature>-10</temperature><rain>0</rain></weather>"
        When I run my application
        Then I should get no error
        But I should be able to get weather information

    Scenario Outline:
        Given value <cloud> for clouds
        When I call cloudiness
        Then I should get cloudiness <cloudiness>

        Examples:
            | cloud | cloudiness    |
            | 0     | bright        |
            | 20    | partly cloudy |
            | 50    | cloudy        |
            | 90    | clouded       |

    Scenario:
        Given value 20 for clouds
        And value 27 for temperature
        And value 0 for rain
        When I call summary
        Then I should get summary "a beautiful warm day"

(więcej przykładów znajdziecie tutaj: https://github.com/Behat/Behat/tree/master/features)

Testy jednostkowe

Zastosowanie kilku prostych rozwiązań, takich jak np. używanie nazewnictwa testów jednostkowych przed implementacją funkcjonalności w formie pełnych zdań z użyciem słowa „should” (z ang. „powinien”), pomaga programistom pisać bardziej sensowne testy, co z kolei przekłada się na pisanie kodu wyższej jakości.

public class WhenTransferringInternationalFundsTest {

class WhenTransferringInternationalFundsTest
{
    public function testShouldTransferFundsToLocalAccount()
    {
        ...
    }

    public function testShouldTransferFundsToDifferentBank()
    {
        ...
    }

    public function testShouldDeductFeesAsSeparateTransaction()
    {
        ...
    }
}

Podsumowanie

W tekście przedstawiłem jedynie część elementów ze zbioru praktyk BDD. Pełne wdrożenie BDD w organizacji wymaga wykorzystania odpowiednich narzędzi w zależności od języka programowania w jakich budujemy rozwiązania. Daje to wymierne korzyści takie jak: automatycznie generowanie szablonów testów, generowanie dynamicznej specyfikacji niskiego poziomu, a także możliwość śledzenia etapów poszczególnych implementacji oraz ich statusów. Przedstawione praktyki mogą być wykorzystywane w każdej organizacji i w każdym projekcie praktycznie od zaraz.

Czytelnikom zainteresowanych technikami BDD polecam zapoznać się z publikacją „BDD w działaniu. Sterowanie zachowaniem w rozwoju aplikacji” autorstwa Johna Fergusona Smarta, która opisuje szczegółowo całe zagadnienie.