Gherkin: techniczno-poetycki język

W idealnym świecie IT, kiedy uczestniczymy w procesie wytwarzania oprogramowania (jako programiści lub testerzy), chcemy aby wszystko było zrozumiałe. Począwszy od dokumentacji produktu, skończywszy na wynikach testów. Na każdym etapie staramy się zobrazować interesariuszom, jakość tworzonego produktu lub kolejnej aktualizacji softu.

Niewątpliwie, jednym z większych wyzwań dla całego zespołu stanowi właśnie stworzenie dokumentacji. Tak, aby była zunifikowana, przejrzysta i zrozumiała dla wszystkich ludzi pracujących nad danym produktem.

Pojawia się zatem pytanie:

Jak można połączyć aspekty biznesowe z deweloperskimi, w taki sposób, aby dla jednej i drugiej grupy było wszystko zrozumiałe?

Z pomocą przychodzi nam język Gherkin! To język, który daje możliwość opisania w "poetycki" sposób aspektów technicznych, które będą zrozumiałe dla osób nieobeznanych z technikaliami tworzenia oprogramowania.

Gherkin? A co to?

Gherkin to język służący do tworzenia przypadków testowych. Jest językiem naturalnym, opisowym, bardzo podobnym do tego, którego używamy na co dzień. Oczywiście musimy tutaj zaznaczyć, że wywodzi się z takiego podejścia jak BDD – Behavior-driven development.

Co tak naprawdę daje nam język Gherkin?

• możliwość spisania wymagań produktu w sposób jasny, przejrzysty i zrozumiały dla osób technicznych i nietechnicznych
• automatyczne testowanie aplikacji z pomocą frameworka – Cucumber
• prowadzenie dokumentacji o faktycznym zachowaniu się systemu
• w nieskomplikowany sposób prezentowanie wyników testów automatycznych dla wszystkich interesariuszy
• idealny do kryteriów akceptacji np. funkcjonalności

Cechy charakterystyczne

Gherkin posiada bardzo charakterystyczną budowę i nieskomplikowaną składnię. W skład pełnego scenariusza wchodzą następujące elementy – słowa kluczowe:

• Feature
• Scenario
• Given
• When
• Then
• And

Dodatkowymi opcjami są: Scenario Outline, Examples, Background i But – które rozwinę w dalszej części.

Poznaliśmy już słowa kluczowe, z których będziemy korzystać w “większości” przypadków stosując ten język. Natomiast jak wygląda struktura i co oznaczają poszczególne elementy?

1. Feature

Feature: Tworzymy w tym miejscu opis danej funkcjonalności

• przykład:
  Feature: Funkcjonalność – logowanie do aplikacji

2. Scenario

Scenario: Krótki, zwięzły i przejrzysty opis tego, co scenariusz będzie wykonywał

• przykład:
  Scenario: Jako niezalogowany użytkownik, chciałbym zalogować się do aplikacji

3. Given

Given W tym miejscu definiujemy nasze warunki początkowe

• przykład:
  Given Jestem na stronie do logowania

4. When

When Służy nam do opisu wykonywanej akcji

• przykład:
  When Wpisuję "nazwa_konta" w polu "Nazwa Użytkownika"

5. Then

Then Służy do zdefiniowania oczekiwanego rezultatu

• przykład:
  Then Strona startowa jest widoczna

6. And  

And Służy do kontynuacji wcześniejszego zdarzenia

• przykład:
  And Przycisk "Wyloguj" jest widoczny

Przykładowy scenariusz dla funkcjonalności logowania może wyglądać następująco:

Feature: Funkcjonalność – logowanie do aplikacji

Scenario: Jako niezalogowany użytkownik, chciałbym zalogować się do aplikacji

Given Jestem na stronie logowania do aplikacji

When Wpisuję "nazwa_konta" w polu "Nazwa Użytkownika"

And Wpisuję "hasło_konta" w polu "Hasło"

And Klikam w przycisk "Zaloguj"

Then Strona startowa jest widoczna

And Przycisk "Wyloguj" jest widoczny

Jak się pewnie domyślacie, dana funkcjonalność będzie posiadała wiele scenariuszy, przykładowo, chcemy sprawdzić poprawność logowania dla użytkowników z różnego rodzaju grup między innymi: zwykłego użytkownika, użytkownika posiadającego subskrypcję a także administratora. Mogłoby się wydawać, powinniśmy napisać trzy różne scenariusze, prawda? Nic bardziej mylnego! Gherkin umożliwia nam stosowanie Scenario Outline i Examples, czyli w jednym zdefiniowanym scenariuszu możemy umieścić kilka przykładów.

Jak to wygląda w praktyce?

Stworzyliśmy tabelę z naszymi przykładami, które chcemy umieścić w jednym scenariuszu. Nazwa kolumny oznacza jakie przykłady kryją się pod nią. Tę nazwę umieszczamy w scenariuszu pomiędzy znacznikami “< >”.

Przydatnym dodatkowym słowem kluczowym spoza podstawowego zestawu jest Background, który daje nam możliwość wydzielania unifikowanych kroków “Given” np. Given Jestem zalogowany.

Kolejny ze słówek rozszerzających jest “But”, ale w przypadku mojej osoby i doświadczenia z powyższym językiem jest ono raczej nieużywane. Stosujemy je w podobnych sytuacjach co “And” czyli np.

Then Strona startowa jest widoczna

But Nie widzę przycisku do logowania

Kryteria akceptacji a Gherkin

Pokrycie kryteriów akceptacji jest jednym z uciążliwych tematów. Musimy zdefiniować coś co w zasadzie będzie wytyczną do uznania pracy za skończoną i zaakceptowaną przez użytkownika, klienta tudzież osoby uprawnionej do akceptacji danej “historyjki”.

Moim zdaniem język Gherkin pomaga nam w tym zadaniu. Dzięki czemu nie tworzymy “checklisty”, która tylko odhacza ptaszki punkt po punkcie. Natomiast utworzone kryteria akceptacji w omawianym języku są czytelne i jednoznaczne.

Dodatkowo, mamy ułatwioną możliwość zautomatyzowania takiego prostego scenariusza, który np. po skończonej implementacji zaświeci nam się zielonym kolorem i będziemy mieć klarowną sytuację, że coś (historyjka, lub jej część) zostało ukończone a “sprint” możemy uznać za udany.

Język, języka

Wszystkie przykłady słów kluczowych zostały przetłumaczone na język polski, aby sens stosowania Gherkina był jasny. Natomiast należy pamiętać, że w wersji domyślnej używamy języka angielskiego, poniżej zamieszczam tabelę z odpowiednikami w języku polskim:

Możecie ją również znaleźć na stronie twórców frameworka Cucumber – który jest nieodłącznym elementem języka Gherkin.

Reasumując

Implementacja języka Gherkin w naszym procesie wytwarzania oprogramowania zaowocuje przejrzystą i klarowną dokumentacją produktu, a także zrozumiałymi testami automatycznymi dla osób nietechnicznych. Wymaga to wiele czasu, aby każda z osób w projekcie zrozumiała tak naprawdę po co to jest wdrażane i jaki efekt za tym idzie.

Rada jest prosta, nie zrażajcie się i brnijcie naprzód! 🙂

Paweł Gwozdecki

Specjalista ds. automatyzacji testów

Uczestnik drużynowych mistrzostw Polski w testowaniu oprogramowania oraz laureat testerskiego hackathonu. Obecnie pracuje jako specjalista ds. automatyzacji testów. Hobbystycznie pogłębia swoje kompetencje z zakresu zarządzania procesem testowania. Uwielbia bughunting, czyli możliwość wykonywania testów eksploracyjnych.