Pisanie lepszych historyjek użytkownika za pomocą Gherkina i Cucumbera

Pisanie zautomatyzowanych testów jednostkowych dla oprogramowania, które budujemy, może wydawać się dużą ilością pracy u podstaw bez wyraźnej korzyści. Jednakże, długoterminowe korzyści dla zdrowia, szczęścia i szybkości Twojego zespołu przewyższają początkową inwestycję. Wśród wielu innych korzyści, zautomatyzowane testy wyłapują błędy, umożliwiają ciągłe wdrażanie i ułatwiają programistom pracę nad nieznanym kodem.

Cucumber jest narzędziem, które pozwala nam tworzyć zautomatyzowane testy oprogramowania w łatwy do napisania i czytelny sposób. Chociaż wiele zespołów produktowych ma problemy z uruchomieniem zautomatyzowanych testów (być może nigdy nie słysząc o narzędziach takich jak Cucumber), prawie wszystkie z nich nieświadomie miały do czynienia z jednym z jego kluczowych komponentów – Gherkin.

Przy rozsądnym użyciu, pisanie kryteriów akceptacji w formie Gherkin jest świetnym sposobem dla zespołów na zdefiniowanie i uzgodnienie tego, co „zrobione” oznacza dla funkcji, które budują. Pomimo swojej prostoty, Gherkin jest bardzo zniuansowanym językiem. Z tym niuansem wiąże się wiele nieporozumień dotyczących tego, co oddziela dobrze napisaną deklarację od tej, która jest napisana źle, szczególnie dla osób, które dopiero poznają Gherkina.

W oderwaniu od kontekstu, dziwactwa Gherkina mogą wydawać się mylące, ale kiedy spojrzy się na nie w kontekście zautomatyzowanych testów Cucumber, te subtelności nabierają dużo więcej sensu. Ten artykuł opisuje jak Gherkin i Cucumber pasują do siebie, tak abyś mógł zobaczyć jak używać Gherkin bardziej efektywnie już dziś. Pod koniec tego artykułu, dowiesz się jak działa pełna implementacja Gherkin + Cucumber i jak budowanie biblioteki dobrze napisanych scenariuszy Gherkin toruje drogę do zautomatyzowanych testów.

Gherkin jest specyficznym dla domeny językiem do pisania kryteriów akceptacji, który ma pięć głównych stwierdzeń:

1. Scenario – etykieta dla zachowania, które zamierzasz opisać
2. Given – stan początkowy. scenariusza
3. When – konkretna akcja, którą podejmuje użytkownik
4. Then – testowalny wynik, zazwyczaj spowodowany działaniem w When
5. And – to kontynuacja dowolnego z pozostałych trzech operatorów

Wraz z tymi stwierdzeniami opisujemy wszystkie działania, które użytkownik musi podjąć, aby wykonać zadanie oraz wynik tych działań.

Na przykład, przykład prawdziwego Gherkina może wyglądać tak:

Scenario: User clicks the link
Given I am on the homepage
When I click the provided link
Then I should see the link click confirmation

Albo generalizując, tak:

Scenario: Some determinable business situation
Given some precondition
And some other precondition
When some action by the actor
And some other action
And yet another action
Then some testable outcome is achieved
And something else we can check happens too

Generalnie rzecz biorąc, Kierownik Produktu pisze kryteria akceptacji Gherkina zanim zespół rozpocznie pracę nad daną funkcjonalnością. Posiadanie kryteriów akceptacji nakreślonych w łatwej do odczytania i zrozumienia strukturze sprawia, że programistom i projektantom dużo łatwiej jest zrozumieć zamierzony przepływ użytkownika. Jest to cenne samo w sobie, ale to tylko niewielka część wartości dobrze ustrukturyzowanego Gherkina. W końcu istnieje wiele skutecznych sposobów pisania opisów funkcji (takich jak: As a ___ I want to ___ so that ___), które mogą ułatwić komunikację.

Te inne podejścia mają swoje miejsce i w wielu przypadkach są kompatybilne z Gherkinem. Jednakże, gdy wyjdziemy poza ręczne QA i przejdziemy do testów automatycznych, prawdziwa wartość Gherkina wysuwa się na pierwszy plan. Dzięki kilku sprytnym technikom, angielskie scenariusze Gherkin, które piszemy, mogą być automatycznie przetłumaczone na testowalny, zautomatyzowany kod. Aby zobaczyć, co mam na myśli, spójrzmy na starszego brata Gherkina – Cucumbera.

Wyrażenia regularne

Tłumaczenie scenariuszy Gherkina na kod wykorzystuje technologię zwaną Wyrażeniami regularnymi, lub jak się ją powszechnie określa, Regex.

Problemem, który rozwiązuje Regex, jest znajdowanie określonych słów, fraz lub znaków w tekście. Aby osiągnąć ten cel, twórcy Regex zdefiniowali zestaw znaków i symboli, które reprezentują logikę stojącą za dopasowywaniem części tekstu. Na przykład, $ jest używane do oznaczania końca łańcucha znaków. W związku z tym, wyrażenie regularne fox$ pasowałoby do silver fox (ponieważ ostatnie trzy litery to f-o-x), ale nie do foxy (ponieważ ostatnią literą jest y).

Cucumber używa Regex do skanowania scenariuszy, które definiujemy dla słów kluczowych Gherkina (ScenarioGivenWhenThen, oraz And) oraz frazy, które po nich występują. Kiedy Cucumber znajduje frazę, którą rozpoznaje w jednym z naszych scenariuszy używając Regex, tłumaczy tę frazę na kod używając czegoś co nazywamy Definicjami Kroków.

Definicje Kroków

Pliki definicji kroków są jak słownik języków obcych. Dają one naszemu pakietowi testowemu sposób na przetłumaczenie kroków angielskiego scenariusza na kod, który możemy uruchomić. W większości zespołów, definicje kroków piszą programiści, którzy zbudują daną funkcjonalność.

Pliki definicji kroków wyglądają mniej więcej tak:

Pierwsze stwierdzenie mówi „za każdym razem, gdy znajdziesz ciąg 'Idę na stronę główną' wtedy uruchom funkcję visit root_path„.

Drugie stwierdzenie mówi „za każdym razem, gdy znajdziesz ciąg 'Powinienem zobaczyć wiadomość powitalną' wtedy oczekujemy, że bieżąca strona będzie miała tekst 'Hello Cucumber' gdzieś na niej”.

Każdy krok w scenariuszu powinien mieć definicję kroku, tak aby zestaw testów automatycznych wiedział jak przetłumaczyć nasz angielski na kod. Z czasem napiszesz setki takich definicji kroków, z których wiele nadaje się do ponownego użycia w całym zestawie testów (jak np. pierwszy krok zdefiniowany powyżej).

Caveat: Ponowne użycie funkcji jest możliwe tylko wtedy, gdy używamy pojedynczego wyrażenia dla pojedynczej akcji. Jeśli nasze scenariusze używają zamiennie zarównoI go to the homepage jak i I visit the homepage, to musimy utrzymywać dwie oddzielne definicje kroków dla tej samej akcji. Ten zduplikowany kod sprawia, że nasz zestaw testów jest trudniejszy w utrzymaniu i narusza zasadę DRY (don’t repeat yourself) rozwoju oprogramowania.

As our applications and our test suites grow our step definitions and our number of scenarios grow alongside them. To może szybko stać się niechlujne i przytłaczające. Aby pomóc w organizacji naszych pakietów testowych, używamy plików funkcji.

Pliki funkcji

Aby pomóc w zarządzaniu złożonością dużego pakietu testowego, grupujemy nasze scenariusze Gherkin w pliki funkcji. Pliki cech są jak wirtualna lista kontrolna, dzięki której możemy mieć pewność, że nasze oprogramowanie działa. Oprócz scenariuszy potrzebnych do przetestowania funkcji, pliki cech zawierają również krótki opis funkcji oraz wszelkie reguły biznesowe lub dodatkowe informacje, które pomagają opisać, co dana funkcja robi.

Plik cech może wyglądać mniej więcej tak:

Feature: Some terse yet descriptive text of what is desired
Textual description of the business value of this feature
Business rules that govern the scope of the feature
Any additional information that will make the feature easier to understand
Scenario: Some determinable business situation
Given some precondition
And some other precondition
When some action by the actor
And some other action
And yet another action
Then some testable outcome is achieved
And something else we can check happens too Scenario: A different situation
...

Aplikacja może (i powinna) posiadać wiele plików cech, które opisują, jak działają jej funkcje. Testy te współpracują ze sobą, aby dać ci przegląd stanu zdrowia twojej aplikacji.

Wyjście

Gdy uruchomisz swój zestaw testów w linii poleceń używając Cucumbera, otrzymasz wyjście coś takiego:

$ cucumber -s
Using the default profile...
Feature: Hello CucumberScenario: User sees the welcome message
When I go to the login page
Then I should see the welcome message1 scenario (1 passed)
2 steps (2 passed)
0m0.148s

Albo coś bardziej namacalnego:

$ cucumber -s
Using the default profile...
Feature: Google Homepage SearchScenario: User sees the header
Given I’m on the homepage
Then I see the headerScenario: User can search with "Google Search”
Given I’m on the homepage
When I type "random page” into the search field
And I click the Google Search button
Then I go to the random page search resultsScenario: User can search with "I’m Feeling Lucky”
Given I’m on the homepage
When I type "random page” into the search field
And I click the I’m Feeling Lucky button
Then I go to a random pageScenario: User can see the Terms and Conditions
...15 scenarios (15 passed)
87 Steps (87 passed)
0m3.141s

Patrząc na dane wyjściowe z uruchomienia zestawu testów, masz natychmiastowy sposób na sprawdzenie swojej aplikacji. Może pokazać, gdzie Twoje zmiany zepsuły kawałek starej funkcjonalności lub gdzie nowa funkcjonalność nie działa zgodnie z projektem. Ułatwia to ustalenie i naprawienie tych problemów tak, abyś mógł wysłać produkt z zaufaniem.

Podsumowanie

Użycie Gherkina do pisania scenariuszy ułatwia pokazanie przepływów, które produkt musi posiadać. Pliki cech pomagają zorganizować te przepływy w logiczne kawałki. Cucumber skanuje te kawałki i daje nam bieżący odczyt tego, które elementy naszego oprogramowania działają, a które nie.

Pełny zestaw testów, gdzie każda cecha ma swój plik cech i zestaw scenariuszy jest potężnym narzędziem. Ułatwia wyłapywanie błędów w nowych funkcjach, unikanie wprowadzania błędów w starych funkcjach i komunikowanie postępów z interesariuszami. Krótko mówiąc, automatyzuje niektóre z największych opóźnień pomiędzy zbudowaniem funkcjonalności a oddaniem jej w ręce użytkowników.

Używanie Gherkina i Cucumbera nie jest jedynym sposobem na budowanie zautomatyzowanych testów kryteriów akceptacji, ale jest to struktura, która jest łatwa do skalowania. Możesz zacząć pisać Gherkin od razu, a gdy twój zespół dojrzeje i rozrośnie się, zacznij dodawać pliki krokowe i zautomatyzowane testy z Cucumber. Kiedy są używane efektywnie, Cucumber i Gherkin dają nam jasną (i iteracyjną!) ścieżkę w kierunku pełnych i zautomatyzowanych testów jednostkowych.