Testy oprogramowania: dobre praktyki BDD

Dobre praktyki BDD to bez wątpienia jeden z elementów prowadzenia efektywnych testów oprogramowania. Początkowo podejście to było ukierunkowane na wsparcie procesów tworzenia oprogramowania w stosunkowo małej skali. Obecnie bardzo dobrze sprawdza się nawet w bardziej zaawansowanych projektach. Czym jest BDD? To metodyka rozwoju oprogramowania, która sterowana jest zachowaniem (BDD – Behavior-driven development). Zainteresowani szczegółami? Z tekstu dowiecie się:

• czym dokładnie jest podejście BDD?
• jak schematycznie opisać założenia BDD?
• na co zwrócić uwagę tworząc scenariusze testów?
• jakie elementy powinny znaleźć się w feature? W scenario?  Jakie w części steps?

BDD – czyli, o co chodzi?

W praktyce podejście BDD udoskonala praktyki inżynierii oprogramowania w taki sposób, by koncentrować uwagę na dostarczaniu rozwiązań coraz wyższej jakości. Dzięki temu, że wszystkie strony (klient, analityk biznesowy, tester, developer) zaangażowane w proces twórczy działają w oparciu o ujednolicone ramy pojęć, prace przebiegają efektywnie. BDD nie koncentruje się na samej implementacji systemu. Tutaj uwaga skierowana jest przede wszystkim na jego pożądane zachowanie. Innymi słowy: sprawdzamy, jak powinien zachowywać się tworzony system, w zależności od wstąpienia wyznaczonych warunków oraz działań użytkownika. W BDD zaczynamy od tworzenia historyjek użytkownika aby móc ustalić wymagania. Historyjki to scenariusze, które opisane są w sposób zrozumiały dla wszystkich zaangażowanych stron. Służy nam do tego język Gherkin, który wywodzi się z podejścia BDD.

Schematycznie założenia BDD przy użyciu języka Gherkin można opisać w następujący sposób:

• GIVEN – wstępne warunki/konieczny warunek, który musi być spełniony aby rozpocząć scenariusz
• AND –  może występować jako kontynuacja Given
• WHEN – akcja, która ma wywołać jakieś zachowanie w aplikacji
• AND – może występować jako kontynuacja When
• THEN – oczekiwany rezultat wykonanej akcji

Powyższe kroki w zupełności wystarczą nam do tworzenia dynamicznie zmieniającej się dokumentacji wymagań w trakcie tworzenia oprogramowania, które jest bardziej zorientowane na potrzeby użytkowników.

Dobre praktyki BDD

Warto przy tym zachować następującą kolejność działań: feature -> scenario -> steps

Co kryje się pod wskazanymi pojęciami i o czym jeszcze należy pamiętać?

• Feature – opisz funkcjonalność
• Scenario – opis co weryfikujesz w scenariuszu – co ma się wydarzyć
• Steps – napisz reużywalne kroki, historyjkę użytkownika (given, and, when, then)
• Background – założenie, kroki, które są wspólne dla różnych scenariuszy
• Scenario Outline – tworzony dla scenariusza z dodatkowo różnymi przypadkami testowymi
• Examples – przypadki testowe, zmienne

Dobre praktyki BDD – o czym pamiętać tworząc scenariusz?

Najlepiej wyjaśnić cały proces w oparciu o wskazany wcześniej schemat: feature -> scenario -> steps

Feature:

• opis funkcjonalności – co powinno się wydarzyć po przejściu scenariusza

Scenario:

• każdy scenariusz powinien być możliwy do wykonania samodzielnie
• tytuł scenariusza skierowany na zachowanie, powinien odpowiadać na pytanie “Co chcę przetestować?”
• Scenario Outline używamy, gdy chcemy zapisać  różne przypadki testowe dla 1 scenariusza. Aby zapisać prawidłowo scenariusz, dla “miejsca”, które będzie parametryzowane należy użyć “< >”. Stosując zapis zgodny ze zdjęciem poniżej.

Schemat zapisu:

Feature: opis funkcjonalności

Scenario Outline: tytuł (opis tego, co będzie testowane, co weryfikujemy)

Steps: (reużywalne, podejście imperatywne lub deklaratywne)

Examples: zmienna zapisana w < >

Przykłady przypadków testowych dla 1 użytkownika:

• prawidłowy scenariusz zapisu przypadków testowych dla tego samego użytkownika:

• błędny scenariusz zapisu przypadków testowych dla tego samego użytkownika:

• Backgorund używamy dla zapisu kroków, które powtarzają się w scenariuszach dla tej samej funkcjonalności

Schemat zapisu:

Feature: opis funkcjonalności

Background: kroki, które będą się powtarzać

Scenario: tytuł (opis tego, co będzie testowane, co weryfikujemy)

Steps: (reużywalne, podejście imperatywne lub deklaratywne)

Przykład:

• Scenariusze przed zastosowaniem Background:

• Scenariusze po zastosowaniu Background:

Dobre praktyki BDD – o czym pamiętać tworząc scenariusz?

Steps:

• kroki powinny być niezależne, maksymalnie opisowe (przykład: zamiast “zatwierdzam” – “zatwierdzam płatność na stronie głównej”). Nie należy tworzyć identycznych kroków w różnych scenariuszach, chyba że mają dokładnie taki sam cel i wpływ
• When i Then używamy jeden raz w scenariuszu. When i Then w jednym scenariuszu opisuje jedno zachowanie. Jeśli mamy więcej niż jedno zachowanie w scenariuszu, należy je rozdzielić na dwa osobne scenariusze pamiętając o tym, że Given – konfiguruje początek scenariusza – tutaj uwzględnij stan początkowy -> to drugie zachowanie wymaga wykonanie pierwszego. Istnieją oczywiście przypadki, w których stosujemy podwójne When – Then, jednak staramy się ograniczać zapis w ten sposób, ponieważ nie jest to “zgodne” z dobrymi praktykami BDD.
• pisząc kroki używamy  formy 1 lub 3 osoby liczby pojedynczej. Należy zdecydować się na jedną opcję i stosować ją konsekwentnie. Złą praktyką jest używanie obu form osobowych naprzemiennie – scenariusz jest niejasny i niezrozumiały
• dane testowe zapisujemy w Examples, jak na przykładzie poniżej:

• kroki piszemy pod kątem ponownego wykorzystania. Krok zapisany na sztywno, aby wyszukać konkretną frazę, nie nadaje się do wielokrotnego użytku, ale krok sparametryzowany do wyszukiwania dowolnej frazy już tak. Parametryzacja – najlepszą praktyką jest pisanie sparametryzowanych wartości w podwójnych cudzysłowach. Dzięki temu parametry są łatwe do zidentyfikowania. Przykład:

• Podejście imperatywne i deklaratywne – różnice:

Imperatywne kroki koncentrują się na sposobie podejmowania działań. Dlatego często potrzebują wielu kroków, aby w pełni osiągnąć zamierzone zachowanie. Co więcej, zamierzone zachowanie nie zawsze jest tak samo udokumentowane, jak w przypadku kroków deklaratywnych.

Kroki deklaratywne określają,  jakie działania powinny zostać wykonane, bez podawania wszystkich informacji o tym, jak to się stanie. Kierują się zachowaniem, ponieważ wyrażają działanie na wyższym poziomie. Próbując zmniejszyć liczbę kroków, zadaj sobie pytanie, czy Twoje kroki można zapisać bardziej deklaratywnie?

Przykład dotyczący testów tej samej funkcjonalności, zapisany za pomocą dwóch różnych podejść:

• w sposób imperatywny (krok po kroku, co ma się wydarzyć):

Given: otworzyłam stronę logowania

When: wpisuję login w pierwszym polu tekstowym

And: wpisuję hasło w drugim polu tekstowym

And: klikam przycisk Zaloguj

Then: widzę spersonalizowaną stronę

• w sposób deklaratywny (deklarujesz pożądane rezultaty ale nie krok po kroku):

Given: otworzyłam stronę logowania

When: loguję się prawidłowymi danymi

Then: widzę spersonalizowaną stronę

Podsumowanie

Wykorzystanie dobrych praktyk BDD w tworzeniu scenariuszy testowych nie tylko ułatwia działania, ale i przekłada się na zapewnienie jakości projektowanego systemu/aplikacji w sposób niezwykle efektywny. W Opsenio doskonale wiemy, jak ważnym elementem działań projektowych jest prowadzenie testów. Chcesz poznać więcej szczegółów? Zapraszamy do kontaktu.