menu

// Behaviour-driven Development w testach automatycznych

Czy warto inwestować w Behaviour-driven Development (BDD) podczas tworzenia testów automatycznych? Jakie są wady i zalety takiego rozwiązania? Przyjrzyjmy się temu zagadnieniu i przeanalizujmy dostępne dla niego narzędzia.

BDD w skrócie

Nie będę się rozpisywać o tym, czym jest BDD – takich opracowań jest mnóstwo. Warto natomiast przypomnieć sobie kilka podstawowych faktów:

  • BDD skupia się na tym, w jaki sposób dana funkcjonalność powinna się zachować
  • Scenariusze testowe piszemy w formie historyjek przy użyciu języka Gherkin – w efekcie przyjmują one następującą formę:

Feature: Adding a trip to shop cart
Scenario: As a user I am able to add a trip to shop cart
Given user is on main page
When he sets Paris as destination in the search form,
And submits his request
And goes to the first found result record
And clicks on “add to cart button”
Then a new item is added to the cart
And the item’s description contains proper data
And overall price is counted properly

  • FEATURE – opis danej funkcjonalności
  • SCENARIO – opis tego, co test ma sprawdzić/wykonać
  • GIVEN – warunek początkowy
  • When – wykonanie akcji
  • THEN – weryfikacja oczekiwanego rezultatu/wyniku
  • AND – słowo kluczowe, które informuje o kontynuacji powyższego kroku

Oprócz powyższych, wśród słów kluczowych i adnotacji, jakie mogą się pojawić w naszej historyjce, są: BACKGROUND, EXAMPLES, SCENARIO OUTLINE, BUT czy TAG.

Po co używać BDD?
Największą zaletą tej metodologii jest czytelność historyjek dla wszystkich użytkowników – od dewelopera po klienta końcowego. Dobrze opisany scenariusz od razu dostarcza informacji o tym, jaka funkcjonalność jest sprawdzana oraz jaki jest cel poszczególnych kroków. Mamy zatem wiedzę o tym, co jest testowane, bez konieczności zagłębiania się w kod itp.

Jeśli dołączymy do tego system raportów (np. Allure), uzyskamy przejrzyste podsumowanie wykonanych testów. Zaś w razie niepowodzenia, otrzymujemy informację, w którym kroku wystąpił problem. Tymczasem praktyka biznesowa pokazuje, że klient często rozważa sens wprowadzenia do projektu automatyzacji testów. Dzieje się tak, ponieważ nie ma on pewności, co tak naprawdę jest weryfikowane.

Tego typu wątpliwości pomagają rozwiać testy napisane właśnie w BDD, które – co warto podkreślić – są łatwe do utrzymania, a raz opracowane kroki można następnie wykorzystywać w wielu historyjkach.

Czy warto?
Jak najbardziej tak! Jednak bardziej szczegółowa odpowiedź na takie pytanie wymaga odniesienia się do konkretnej sytuacji projektowej. Omówmy zatem różne przypadki:

  • PROJEKT STARTUJE OD ZERA
    Jeżeli nasz projekt dopiero będzie miał kick-off, na pewno warto iść w stronę BDD. Przemawiają za tym: czytelność, łatwość w utrzymaniu i przyjazny podgląd na testy dla osób nietechnicznych.
    Na tym etapie warto mieć świadomość, że nawet jeśli teraz nie jest to nam potrzebne, w przyszłości może się to zmienić.
  • PROJEKT JEST W ZAAWANSOWANEJ FAZIE ROZWOJU
    Jeśli mamy już przygotowane testy automatyczne i działają one poprawnie, nie wymagając szczególnego nakładu pracy ponad ich utrzymanie, wówczas raczej nie ma sensu przechodzić na BDD.
    Jeżeli jednak jesteśmy zdecydowani na tę metodologię, wówczas najlepiej będzie zacząć od pisania nowych scenariuszy, a obecne pozostawić bez zmian. Jeżeli czas na to pozwoli i będzie taka potrzeba, to zawsze można do nich wrócić i je zmodyfikować na dalszym etapie projektu.

Słabe strony
Decydując się na wykorzystanie Behaviour-driven Development musimy pamiętać, że tym samym implementujemy dodatkową warstwę abstrakcji – trzeba zaprogramować poszczególne kroki naszej historyjki. Oprócz tego należy uwzględnić czas niezbędny, by odpowiednio opisać sam scenariusz. Czy trzeba to traktować jako wadę? Odpowiedź zależy od konkretnych potrzeb – swoich i danego projektu. Warto jednak pamiętać, że tradycyjne testy pisane „samym kodem”, mogą – z drugiej strony – wymagać więcej czasu, aby zrozumieć, co tak naprawdę weryfikują.

BDD? Jestem na tak… i co dalej?
Wykorzystując do automatyzacji testów język Java, możemy użyć wielu narzędzi wspierających BDD. Warto spośród nich wspomnieć następujące: JBehave, Cucumber i Serenity.

  • CUCUMBER VERSUS JBEHAVE
    Są to frameworki najczęściej stosowane przy automatyzacji testów w Javie. O ile wszystko zaczęło się od JBehave’a stworzonego przez ojca BBD – Dana Northa, o tyle Cucumber jest obecnie numerem jeden. Jego popularność najlepiej obrazuje poniższe zestawienie:

Na pierwszy rzut oba frameworki wyglądają bardzo podobnie. Jednak „diabeł tkwi w szczegółach”, jak głosi porzekadło:

  1. Scenariusze testowe zapisujemy w plikach z rozszerzeniem .story dla JBehave’a, a Cucumber przyjmuje rozszerzenie .feature
  2. Oba frameworki wspierają standardy języka Gherkin. Warto jednak zauważyć, że to Cucumber był w tym przypadku prekursorem
  3. Kolejna różnica dotyczy definiowania kroków testowego scenariusza – w JBehave adnotacja opisywana jest zwykłym tekstem, a parametr poprzedza się znakiem dolara (np. ‘$parametr’). „Ogórek” zaś używa do tego wyrażeń regularnych

Zwolennicy JBehave’a jako duży atut tego narzędzia wskazują tzw. kroki złożone (ang. composite steps). Czyli – w skrócie – możliwość stworzenia jednego kroku, który składa się z kilku innych już wcześniej zdefiniowanych. W teorii pozwala to zaoszczędzić czas, nie powielać kodu, a także ułatwić pisanie scenariuszy. W praktyce może się okazać, że nieumiejętne i nierozważne korzystanie z tej funkcjonalności spowoduje więcej szkód niż przyniosło pożytku. Z tego względu kroków złożonych nie znajdziemy w standardach Gherkina i nie jest zalecane ich praktykowanie. Stąd też Cucumber nie wspiera tego rozwiązania.

Szczegółowy opis różnić między wspomnianymi frameworkami można znaleźć w tym miejscu.

A dodam wniosek z własnych obserwacji, że Cucumber wydaje się być nieco szybszy podczas wykonywania testów, a także lżejszy w obsłudze. Widać też, że rozwój „Ogórka” dzieje się w najlepsze – społeczność skupiona wokół tego narzędzia stale się powiększa, a przejrzysta dokumentacja i wsparcie techniczne (to oficjalne i to na forach internetowych) pozwala w szybki sposób rozwiązać napotkane problemy. Jednocześnie JBehave w dalszym ciągu jest wspierany, ale zarówno dynamika jego rozwoju, jak i społeczność, jest kilkukrotnie mniejsza.

Co ciekawe, w trakcie tworzenia tego tekstu na oficjalnej stronie Cucumbera pojawiła się informacja, że zespół odpowiedzialny za jego rozwój został przejęty przez firmę Smartbear – znaną z takich produktów jak SoapUI, TestComplete, Zephyr, SwaggerHub czy HipTest. Co z tego wyniknie i jakie będzie to miało dalsze konsekwencje? Czas pokaże.

  • SERENITY

Narzędzie to pozwala trochę inaczej podejść do tworzenia testów w BDD. Czyli jak? Bez pisania historyjek w Gherkinie. Kolejne kroki wyglądają następująco:

  1. przygotowujemy klasy zawierające definicje (w postaci adnotacji i metod) poszczególnych kroków
  2. w klasie, w której będziemy wykonywać nasze testy, inicjujemy odpowiednie obiekty oraz ich metody
  3. po ukończonym teście tworzony jest raport, który zawiera m.in. wygenerowaną historyjkę BDD.

Oprócz tego Serenity umożliwia integrację zarówno JBehave’a jak i Cucumbera. Wówczas do łask powraca, oczywiście, składnia Gherkina.

BDD – ciekawostki

  • HIPTEST

Jest to platforma do zarządzania testami w chmurze. Z poziomu przeglądarki internetowej możemy: pisać własne scenariusze, uruchamiać testy, korzystać z narzędzi ciągłej integracji. A to wszystko w rozproszonym środowisku. Jeśli ktoś lubi narzędzia UI, może skorzystać z darmowej wersji próbnej producenta.

  •  JGIVEN

Narzędzie to pozwala na pisanie testów w postaci kodu:
given().metoda().when().metoda().then()metoda

Po wykonaniu testu, otrzymujemy szczegółowy raport. Jedną z jego przydatnych funkcjonalności jest automatyczna zmiana naszego programistycznego zapisu na historyjkę z użyciem języka Gherkin.

  • KARATE

To framework, który służy do testów REST API oraz SOAP w postaci historyjek z wykorzystaniem dobrodziejstwa Gherkina i metodologii BDD, gdzie:

  1. Cała logika jest trzymana w scenariuszach testowych
  2. Kroki oraz specjalne komendy są odgórnie zdefiniowane
  3. Brakujące elementy możemy samodzielnie dopisać w Javie lub JavaScript

Karate ma być, zdaniem autora, alternatywą dla popularnego Rest Assured. O ile jednak wnioski z prostych przykładów są zachęcające, o tyle jednak utrzymanie kilkudziesięciu testów robi się kłopotliwe, nieczytelne i po prostu niewygodne.

Jak widać, BDD potrafi być przydatnym rozwiązaniem. Posiada ono wiele zalet – pod warunkiem, że jego użycie jest uzasadnione. Z własnego doświadczenia mogę również potwierdzić, że to właśnie Behaviour-driven Development potrafi być jednym z silniejszych argumentów przemawiających za wprowadzeniem testów automatycznych w projekcie.

// Partnerzy