Wzorce MSA: Retry Logic

EA - Wstęp do Behavior Driven Development (BDD)

 Współczesne metodyki tworzenia oprogramowania coraz częściej koncentrują się na współpracy między zespołami technicznymi a biznesowymi. Jednym z najskuteczniejszych podejść, które to umożliwiają, jest Behavior Driven Development (BDD). Dzięki BDD zespoły mogą efektywnie komunikować się i precyzyjnie definiować wymagania, co prowadzi do tworzenia bardziej użytecznych i spójnych systemów.



W tym artykule przedstawię, czym jest BDD, jak działają narzędzia takie jak Cucumber i język Gherkin, oraz jak za pomocą narzędzia CuPL można generować scenariusze BDD na podstawie diagramów aktywności generowanych w PlantUML.

Behavior Driven Development (BDD) – czym jest?

BDD to praktyka, która umożliwia zespołom programistycznym i biznesowym współpracę przy definiowaniu zachowania systemu. Podejście to opiera się na scenariuszach, które opisują, jak system powinien działać w różnych sytuacjach. Kluczowe cechy BDD:

  1. Wspólny język: Wszystkie strony zaangażowane w projekt mogą zrozumieć scenariusze, ponieważ są pisane w prostym, naturalnym języku.
  2. Testy jako dokumentacja: Scenariusze stają się żywą dokumentacją, która jest zawsze zgodna z implementacją.
  3. Automatyzacja: Narzędzia takie jak Cucumber pozwalają na automatyczne uruchamianie scenariuszy jako testów.

Narzędzie Cucumber i język Gherkin

Cucumber

Cucumber to popularne narzędzie wspierające BDD. Pozwala na definiowanie zachowania systemu w formie scenariuszy testowych i automatyczne ich uruchamianie. Główne cechy:

  • Obsługa wielu języków programowania, w tym Java, Python, Ruby i JavaScript.
  • Integracja z frameworkami testowymi, takimi jak JUnit czy TestNG.
  • Możliwość łączenia scenariuszy z kodem za pomocą tzw. step definitions.

Gherkin

Język Gherkin to rdzeń Cucumbera. Służy do pisania scenariuszy w sposób czytelny zarówno dla programistów, jak i interesariuszy biznesowych. Struktura scenariuszy opiera się na kilku kluczowych słowach kluczowych:

  • Feature: Opis funkcjonalności, która ma być zaimplementowana.
  • Scenario: Konkretna sytuacja testowa.
  • Given: Warunki początkowe.
  • When: Akcja wykonywana w systemie.
  • Then: Oczekiwane rezultaty.

Przykład scenariusza w Gherkin


Feature: Logowanie użytkownika Scenario: Poprawne logowanie Given użytkownik jest na stronie logowania When wpisze poprawne dane logowania Then zostanie przekierowany na stronę główną

Scenariusze te są następnie mapowane na step definitions – fragmenty kodu, które wykonują konkretne akcje.

CuPL

Ciekawym narzędziem jest CuPL -  CLI do automatycznego generowania plików feature Cucumber Gherkin z diagramu aktywności PLantuml

CuPL pozwala nie tylko przekształcać diagramy PlantUML w scenariusze Gherkin, ale również dostosowywać scenariusze za pomocą pliku konfiguracyjnego .cupl.json. Dzięki temu proces tworzenia testów BDD staje się bardziej precyzyjny i dostosowany do potrzeb projektu. 

Generowanie wstępnego scenariusza Gherkin

Uruchom CuPL, aby wygenerować podstawowy plik .feature oraz plik konfiguracyjny .cupl.json:


npx cupl atm.puml

Po uruchomieniu otrzymasz:

  • Plik atm.feature: Wstępny scenariusz Gherkin.
  • Plik atm.cupl.json: Plik konfiguracyjny do dostosowania scenariuszy.
Dostosowanie scenariuszy za pomocą .cupl.json

Otwórz wygenerowany plik .cupl.json i dostosuj go do swoich potrzeb. Przykład konfiguracji:


{ "$schema": "https://raw.githubusercontent.com/cinoss/cupl/master/src/config.schema.json", "global": { "alias": { "PIN is correct": "User enters the correct PIN", "PIN is incorrect": "User enters an incorrect PIN" }, "dialect": "en" }, "paths": { "PIN is correct|Balance is sufficient": { "name": "Successful transaction" }, "PIN is correct|Insufficient balance": { "name": "Insufficient funds", "tags": ["important"] }, "PIN is incorrect": { "alias": { "enter PIN": "User provides PIN <input>" }, "examples": [ ["input"], ["1234"], ["0000"] ] } } }
Co możesz zrobić w .cupl.json?
  • Zmiana nazw scenariuszy: Użyj pola name w sekcji paths, aby nadać sensowne nazwy.
  • Aliasowanie kroków: Użyj alias, aby zmienić nazwy kroków.
  • Dodawanie tagów: Dodaj tags, aby oznaczyć scenariusze specjalnymi etykietami.
  • Dodawanie przykładów: Użyj examples, aby zdefiniować parametry w krokach scenariuszy.
  • Zmiana języka: Pole dialect umożliwia ustawienie innego języka Gherkin.
Generowanie ostatecznego scenariusza Gherkin

Po wprowadzeniu zmian w .cupl.json, uruchom CuPL ponownie z flagą -w, aby wygenerować zaktualizowany plik .feature:


npx cupl -w atm.puml

Wygenerowany plik .feature będzie dostosowany zgodnie z ustawieniami w .cupl.json.

Przykład wygenerowanego scenariusza

Plik .feature po dostosowaniu


Feature: ATM Transactions Scenario: Successful transaction Given User enters the correct PIN When Balance is sufficient Then Dispense Cash Scenario: Insufficient funds @important Given User enters the correct PIN When Insufficient balance Then Show Error Scenario Outline: Invalid PIN Given User provides PIN <input> Then Retry Examples: | input | | 1234 | | 0000 |

Podsumowanie

BDD to podejście, które łączy techniczne i biznesowe aspekty tworzenia oprogramowania. Dzięki narzędziom takim jak Cucumber, Gherkin i CuPL, zespoły mogą tworzyć czytelne scenariusze, które są jednocześnie testami, dokumentacją i mogą mieć swój początek z diagramów aktywności.

Jeśli chcesz usprawnić współpracę w zespole, poprawić jakość kodu i tworzyć bardziej zrozumiałe systemy, wypróbuj BDD w połączeniu z narzędziami do automatyzacji i wizualizacji. Behavior Driven Development to nie tylko metoda, ale i sposób myślenia o współczesnym tworzeniu oprogramowania.


Komentarze