Behavior-driven development

Z Wikipedii, wolnej encyklopedii
Przejdź do nawigacji Przejdź do wyszukiwania

W inżynierii oprogramowania, Behavior-driven development (BDD) – proces wytwórczy oprogramowania który powstał na podstawie procesu Test driven development (TDD)[1][2]. BDD to połączenie wspólnych metod i zasad TDD z cechami procesu domain-driven design (DDD) i obiektowo-zorientowanej analizy i projektowania (OOAD) w celu dostarczenia zespołom tworzącym oprogramowanie oraz zespołom zarządzającym wspólne narzędzia umożliwiające współpracę przy tworzeniu oprogramowania[3].

Chociaż BDD to głównie pomysł na to, jak rozwój oprogramowania powinien być zarządzany zarówno przez interesy biznesowe, jak i wiedzę techniczną, praktyka BDD zakłada wykorzystanie wyspecjalizowanego oprogramowania do wspierania procesu rozwoju. Chociaż narzędzia te są często dedykowane projektom BDD, mogą być postrzegane jako specjalistyczne formy narzędzi obsługujących rozwój oparty na testach. Narzędzia służą do automatyzacji wszechobecnego języka, co jest głównym tematem BDD.

BDD jest w dużej mierze ułatwiony dzięki użyciu prostego języka specyficznego dla danej domeny (ang. Domain specific language - DSL) z wykorzystaniem składni języka naturalnego (np. Zdań w języku angielskim), które mogą wyrażać zachowanie i oczekiwane rezultaty. Testy od dłuższego czasu są popularnym zastosowaniem języków dziedzinowych o różnym stopniu zaawansowania. BDD jest uważane za skuteczną praktykę techniczną, zwłaszcza gdy "zakres problemu" zagadnienia biznesowego które trzeba rozwiązać jest złożony[4].

Historia[edytuj | edytuj kod]

BDD jest rozszerzeniem praktyki rozwoju poprzez testy: rozwoju który korzysta z prostego, dziedzinowego języka skryptowego. Te języki przekształcają zdania języka naturalnego w wykonywalne testy.Wynikiem jest bliższy związek z kryteriami akceptacji dla danej funkcji i testami używanymi do sprawdzania poprawności tej funkcjonalności. W tej postaci jest to ogólne rozszerzenie metodyki TDD.

BDD skupia się na następujących aspektach:

  • Od czego zacząć w procesie
  • Co testować, a czego nie testować
  • Ile można przetestować za jednym razem
  • Jak nazwać testy
  • Jak zrozumieć przyczynę ewentualnego niepowodzenia testu

Głównym celem BDD jest ponowna analiza podejścia testów jednostkowych i akceptacyjnych , które naturalnie pojawiają się w tych kwestiach. Przykładowo, BDD sugeruje, aby nazwy testów jednostkowych były całymi zdaniami zaczynającymi się od warunkowego czasownika (np. w języku angielskim - od czasownika "should" - "powinien") i powinny być pisane w kolejności ich wartości biznesowej. Testy akceptacyjne powinny być napisane za pomocą tzw. "historyjek użytkowników" o następującej strukturze: "jako [rola] chcę [opis oczekiwanej funkcji], aby [opis oczekiwanej korzyści]". Kryteria akceptacyjne powinny być pisane w kategoriach scenariuszy i zaimplementowane w postaci klas: Given [początkowy kontekst], When [opis występującego zdarzenia], then [potwierdzenie wystąpienia oczekiwanego rezultatu] .

Od tego momentu wiele osób opracowało ramy BDD przez kilka lat, definiując je ostatecznie jako platformę komunikacji i współpracy dla programistów, testerów i nietechnicznych lub biznesowych uczestników projektu[5]. Podczas konferencji pt. "Agile specifications, BDD and Testing eXchange" w listopadzie 2009 roku w Londynie, Dan North[6] przedstawił następujący opis BDD:

BDD jest metodologią drugiej generacji, zewnętrzną, opartą na ciągnięciu, wielostronną, wieloskalową, o wysokiej automatyzacji i zwinności. Opisuje cykl interakcji ze ściśle zdefiniowanymi rezultatami, w wyniku czego powstaje działające, przetestowane oprogramowanie, które ma realną wartość.

Dan North stworzył framework BDD o nazwie JBehave, a następnie framework BDD (na poziomie historyjek) dla języka Ruby o nazwie RBehave[7], który później został zintegrowany z projektem RSpec[8]. Pracował również z takimi osobami jak David Chelimsky, Aslak Hellesøy i innymi w celu opracowania testów RSpec, a także napisał książkę pt. "The RSpec Book: Behaviour Driven Development with RSpec, Cucumber, and Friends". Pierwszy, oparty na historyjkach framework w RSpec został później zastąpiony przez narzędzie Cucumber opracowane głównie przez Hellesøy'a. Capybara, która jest częścią platformy Cucumber, jest jednym z takich opartych na sieci oprogramowaniem do automatyzacji testów.

Zasady BDD[edytuj | edytuj kod]

Zgodnie z metodyką TDD, dla każdej jednostki oprogramowania programista musi::

  • najpierw zdefiniować zestaw testów dla danego modułu;
  • doprowadzić do niezaliczenia testów;
  • zaimplementować moduł;
  • na końcu upewnić się, że wdrożenie modułu sprawiło, iż testy zostały wykonane pomyślnie

Ta definicja jest raczej niespecyficzna, ponieważ umożliwia testy pod kątem wysokopoziomowych wymagań oprogramowania, szczegółów technicznych niskiego poziomu lub czegokolwiek pomiędzy. Z tego powodu, BDD można postrzegać jako ciągły rozwój TDD, który dokonuje bardziej szczegółowych wyborów niż TDD.

BDD określa, że testy dowolnej jednostki oprogramowania powinny być opisane pod kątem pożądanego zachowania urządzenia[9]. Zapożyczone z programowania zwinnego pojęcie "pożądanego zachowania" w tym przypadku składa się z wymagań stawianych przez firmę - to jest pożądanego zachowania, które ma wartość biznesową dla dowolnego podmiotu, który zlecił stworzenie danej jednostki oprogramowania. W praktyce BDD jest to określane jako działanie "na zewnątrz".

Lista literatury[edytuj | edytuj kod]

Przypisy[edytuj | edytuj kod]