Istnieje wiele opcji dostępnych dla zespołów, jeśli chodzi o sposób pisania i testowania oprogramowania. Jak określić, której składni użyć i jakie rozwiązanie testowe jest dla Ciebie odpowiednie? W tym poście, zamierzamy zbadać użycie Gherkina i testów Gherkina. Omówimy składnię, jak napisać test oraz zajmiemy się wadami i zaletami.
Te opcje mogą być dobrym wyborem w odpowiednich okolicznościach, ale są pewne względy, o których należy pamiętać zanim się do nich przystąpi, szczególnie gdy weźmie się pod uwagę proces automatyzacji testów.
Zanim omówimy czym jest Gherkin i jak pisać testy Gherkin, jest kilka rzeczy, które musimy najpierw omówić. Ważne jest, aby zrozumieć rolę, jaką odgrywa Behavior-Driven Development (BDD) i jak ta praktyka, Cucumber i Gherkin współpracują ze sobą.
Co to jest BBD?
Behavior-Driven Development (BDD) jest metodą rozwoju, która zachęca do komunikacji pomiędzy zespołami. To podejście oparte na współpracy łączy aspekty biznesowe i techniczne projektów. Metoda ta pozwala zespołom lepiej komunikować wymagania, wcześnie wykrywać problemy i z łatwością utrzymywać oprogramowanie przez długi czas.
Zespoły, które używają BBD mają kilka celów. Pierwszym z nich jest upewnienie się, że wymagania mogą być zrozumiane przez cały zespół. Wtedy zespoły mogą skupić się na zapobieganiu możliwym problemom, zamiast na gaszeniu pożarów, jeśli zostaną one znalezione później. Często oznacza to, że wymagane jest mniej przeróbek.
Prosto możemy opisać ten rozwój w dwóch fazach. Odkrywanie i testowanie.
Po pierwsze, zespoły dowiadują się, czego nie wiedzą, ZANIM zaczną pracować. Wtedy lepiej rozumieją, jak pozostać na dobrej drodze i być bardziej produktywnym.
Jeśli chodzi o testowanie, proces myślenia o testach zaczyna się zanim jeszcze rozpocznie się rozwój. Testy są pisane, aby napędzać implementację i produkt końcowy.
Co to jest Cucumber?
Cucumber jest narzędziem do testowania oprogramowania typu open-source, które wspiera BBD. (Behavior-Driven Development). Działa z Gherkinem, ponieważ składnia Gherkina strukturyzuje zwykły tekst tak, że może on być odczytany przez narzędzie.
Cucumber czyta testy Gherkina i sprawdza, czy kod działa tak, jak powinien. Robi to poprzez pracę poprzez scenariusze i kroki Gherkina. (Więcej na ten temat poniżej). Następnie Cucumber tworzy raport pokazujący każdy krok i scenariusz zakończony sukcesem lub porażką.
Co to jest Gherkin?
Gherkin jest językiem, którego programiści używają do definiowania testów w Cucumberze. Ponieważ język ten używa prostego angielskiego, jest on przeznaczony do opisywania przypadków użycia dla systemu oprogramowania w sposób, który może być odczytany i zrozumiany przez prawie każdego.
Składnia ta promuje rozwój sterowany zachowaniem, ponieważ pozwala programistom, menedżerom, analitykom biznesowym i innym zaangażowanym stronom zrozumieć wymagania projektu i cyklu życia.
Język ten ułatwia tworzenie prostej dokumentacji pisanego kodu. Gherkin dostarcza również skrypty do automatyzacji testów i obsługuje kilkadziesiąt języków.
whitepaper
Behavior-driven development. Komu potrzebny jest Gherkin?
Jak pisać testy Gherkin
Aby pisać testy Gherkin, trzeba najpierw zrozumieć niektóre z używanych słów kluczowych i co robią w praktyce. Oto lista najczęściej występujących słów kluczowych w składni Gherkina.
- Feature
- Rule
- Example
- Given, When, Then, And, But
- Background
- Scenario Outline
Każde słowo kluczowe jest krytyczne dla procesu pisania świetnego testu Gherkina. Teraz, przyjrzyjmy się bliżej tym słowom kluczowym i temu, jak ich używać do pisania testów Gherkin.
Feature
Dokumenty Gherkin zaczynają się od tego słowa kluczowego, po którym następuje tekst, który dostarcza opisu. Mówiąc prościej, feature jest opisem tego, co oprogramowanie ma robić. To słowo kluczowe jest również używane do grupowania scenariuszy razem.
Nie służy to do testowania, ale pozwala na dodanie dokumentacji dotyczącej wymagań i reguł biznesowych. Sekcja opisu kończy się, gdy rozpoczniesz nowy wiersz od jednego z innych słów kluczowych, takich jak zarys scenariusza, przykład lub reguła.
Opisy
Jeśli jest to potrzebne, pod słowami kluczowymi wymienionymi powyżej można również napisać opisy swobodne, pod warunkiem, że żaden z wierszy nie zaczyna się od słowa kluczowego.
Reguła
Słowo kluczowe reguła jest używane do reprezentowania jednej reguły biznesowej, która musi zostać uwzględniona. To zapewnia kontekst dla cechy. Reguły” powinny mieć więcej niż jeden scenariusz, aby pokazać regułę i mogą mieć sekcję tła. (Szczegóły poniżej).
Kroki Gherkin
Następnie, spójrzmy na niektóre z kroków w testach Gherkin. Są to Given, When, Then, And, or But.
Given
Kroki Given ustawiają scenę dla scenariusza. W większości przypadków, kroki te opisują coś, co miało miejsce w przeszłości. To daje systemowi kontekst, zanim użytkownik zacznie z nim współpracować. Z tego powodu nie powinieneś opisywać interakcji użytkownika w tym kroku. Pomyśl o tym co zawierasz w tym kroku jako o warunkach wstępnych.
Uwaga: Możesz mieć więcej niż jeden krok Given.
Kiedy
Kroki Kiedy są krokami akcji. Opisują one zdarzenie. Przykładem może być zdarzenie wywołane przez inny system lub użytkownika wchodzącego w interakcję z nim. Zaleca się, aby mieć tylko jeden krok when dla każdego scenariusza.
Then
Kroki then są krokami rezultatu. To tutaj opisujesz, co chcesz, aby system zrobił, aby można było to porównać z tym, jak oprogramowanie faktycznie działa w praktyce. Powinno to być coś, co można zobaczyć jako rezultat, jak wiadomość lub raport.
And, But
Gdy masz kilka z jednego z typów kroków wymienionych powyżej, możesz użyć and lub but. Pomaga to utrzymać dokumentację zorganizowaną i czytelną.
Tło
Jak wspomniano powyżej, tło pozwala dodać jeszcze więcej kontekstu do scenariuszy w funkcji. W tym miejscu możesz mieć więcej niż jeden krok, w zależności od potrzeb.
Uwaga: Może być tylko jeden krok tła dla każdej cechy. Jeśli potrzebujesz więcej kroków tła, będziesz musiał stworzyć różne pliki cech.
Zarys scenariusza
Zarys scenariusza zawiera sekcję z przykładami. Te kroki czyta się jak szablon. Konspekt scenariusza uruchamia się raz dla każdego wiersza sekcji przykładów z wyjątkiem wiersza nagłówka.
Pros and Cons of Using Gherkin
Teraz, gdy wiesz jak napisać test Gherkin, możesz się zastanawiać jak określić czy jest to odpowiednia opcja dla twojego zespołu. Prawda jest taka, że istnieją zarówno zalety jak i wady używania Gherkina i Cucumbera. Przyjrzyjmy się bliżej kilku z nich.
Gherkin jest prosty
W swoim rdzeniu, Gherkin jest łatwy do zrozumienia zarówno dla deweloperów, jak i kierownictwa biznesowego. W pewnym sensie, jest „nietechniczny”, co ułatwia współpracę pomiędzy zespołami.
Skupia się na wymaganiach projektu
Składnia Gherkin i ten typ testowania jest naprawdę ukierunkowany na projekt i wymagania biznesowe. Zapewnia to proces rozwoju zbudowany z myślą o doświadczeniu użytkownika.
Powtórne wykorzystanie kodu
Sposób, w jaki te testy są napisane, ułatwia ponowne wykorzystanie części kodu innych testów. To może się sumować, oszczędzając czas, pieniądze i zasoby.
Nie dla wszystkich projektów
Gherkin + Cucumber nie jest idealny dla wszystkich typów projektów. Krótkie projekty, które będą wymagały wielu testów, mogą być opóźnione przy użyciu tej metody. Podczas gdy BBD ma swój czas i miejsce, ten sposób myślenia i wdrażania tych testów może spowolnić projekty.
Wymaga dużego zaangażowania
To może być plus lub minus, w zależności od metodologii rozwoju Twojego zespołu. Jak wspomniano wcześniej, Gherkin i Cucumber idą w parze z rozwojem opartym na zachowaniach. Oznacza to, że wymaga to od twojego zespołu ciągłej współpracy, co nie zawsze pasuje do twojego projektu.
Potencjalne wydatki
Chociaż testy te mogą być łatwiejsze do napisania, źle napisany test może skutkować dużą ilością dodatkowego czasu i pieniędzy zmarnowanych, jeśli testy muszą być napisane od nowa. Jeżeli deweloperzy nie rozumieją Gherkina i Cucumbera bardzo dobrze, ten typ testów może być ogromnym ryzykiem finansowym
Przyszłość Gherkina
W Functionize wierzymy, że odejście od Gherkina jest przyszłością i przyniesie lepsze korzyści. Gherkin jest jednym ze sposobów, w jaki ludzie piszą plany testów, ale nie na tym kończy się ten proces. Programiści nadal muszą pisać skrypty testowe. Ten proces może zmarnować wiele czasu, który programiści mogliby spędzić gdzie indziej.
Gherkin jest dobrym pierwszym krokiem do włączenia osób nietechnicznych w testowanie automatyzacji. Ale nasi klienci zwracają się do naszego ALP, ponieważ „wycinamy środkowego człowieka” z konieczności pisania skryptów Selenium i sprawiamy, że tworzenie testów jest łatwe.
Podsumowanie
Gherkin i Cucumber mogą być dobrym wyborem, kiedy potrzebujesz, aby wszyscy w zespole byli zaznajomieni z tematem bez zagłębiania się w aspekty techniczne. Jednakże, w dłuższej perspektywie, taka kombinacja może sprawić, że automatyzacja testów stanie się bardziej skomplikowana, niż jest to konieczne.
Wybór należy do Ciebie, ale zanim wybierzesz składnię i rozwiązanie, rozważ dokładnie za i przeciw. Najważniejszą rzeczą jest to, że Ty i Twój zespół otrzymujecie odpowiednie narzędzia do swoich projektów rozwojowych.
Jednakże naszym zdaniem Gherkin jest po prostu zbyt nieelastyczny i trudny do nauczenia. Naszym rozwiązaniem jest nasz niedawno wydany silnik Adaptive Language Processing (ALP™). Pozwala on na pisanie testów jako serii kroków w prostym języku angielskim.
Niniejszy blog opisywał czym są testy Gherkin, jak pisać testy Gherkin oraz wady i zalety używania tej składni. Mamy nadzieję, że dało ci to wgląd w najlepszy język i opcje testowania dla twojego następnego projektu.