Implementowanie zarysów scenariuszy Cucumber w ramach BDD

Rozwój sterowany zachowaniem (BDD) to zwinna praktyka tworzenia oprogramowania, która usprawnia współpracę między interesariuszami a programistami poprzez używanie prostego, specyficznego dla danej dziedziny języka do opisywania zachowania systemu. 

Jednym z najpotężniejszych narzędzi w BDD jest Cucumber, używany do pisania jasnych specyfikacji. Może być również wykorzystywany w testach z najczęściej używanymi językami programowania, takimi jak Java, Python czy C#, a także integrowany ze strukturami interfejsu użytkownika, takimi jak Selenium, lub używany do testowania interfejsów API.

Zarysy scenariuszy są częścią składni Gherkin języka Cucumber, używanej do pisania wykonywalnych specyfikacji. W przeciwieństwie do zwykłych scenariuszy, które definiują jeden konkretny przykład, zarysy scenariuszy umożliwiają określenie wielu przykładów w formacie tabelarycznym. 

Różnice między scenariuszem a zarysem scenariusza

Scenariusze w języku Cucumber reprezentują przypadek testowy zapisany w podstawowej formie zakładając-kiedy-wtedy. Język Gherkin umożliwia pisanie tych scenariuszy testowych zwykłym językiem angielskim (i w innych językach), dzięki czemu mogą być łatwo rozumiane, a nawet pisane przez osoby nietechniczne. Definicje kroków, które reprezentują implementację kroków, są tworzone w osobnych plikach. 

W przypadku niektórych funkcji sensowne jest powtórzenie tego samego scenariusza z użyciem różnych danych testowych — prawdopodobnie znasz to jako testowanie sterowane danymi. W języku Cucumber robi się to za pomocą zarysu scenariusza z tabelą przykładów zawierającą zestawy danych, które mają zostać użyte. Każdy przykład jest liczony jako osobny test.  

Składnia zarysu scenariusza w języku Cucumber

Typowy projekt Cucumber zawiera pliki funkcji, w których definiowane są testy Cucumber, oraz pliki definicji kroków zawierające implementacje tych kroków. 

Plik funkcji powinien reprezentować specyfikację wymagania oraz scenariusze używane do jego przetestowania. Podstawowa składnia prostego scenariusza Cucumber wygląda następująco:

Scenariusz może również zawierać zmienne, które zostaną potraktowane jako takie w definicji kroku.

Wartości „test”, „nieprawidłowe” i „Nieprawidłowe logowanie” zostaną potraktowane jako zmienne. Zobaczmy teraz, co się stanie, gdy chcemy wypróbować różne kombinacje podanych zmiennych — możemy otrzymać wiele scenariuszy, identycznych z wyjątkiem wartości zmiennych, albo użyć zarysu scenariusza, który pozwala zastosować tabelę, w której definiujemy różne kombinacje danych:

Kombinacja danych jest zapisywana pod słowem kluczowym „Przykłady”, wewnątrz tabeli. Nagłówki tabel to nazwy zmiennych, a każdy wiersz reprezentuje kombinację danych. Każdy przykład w funkcji Cucumber będzie traktowany jako osobny przypadek testowy. 

Tabela przykładów a tabele danych

Tabele przykładów i tabele danych mogą wyglądać podobnie, ale służą do różnych celów. Główna różnica polega na tym, że przykłady służą do implementowania scenariuszy sterowanych danymi, podczas gdy tabele danych są używane, gdy kroki scenariusza muszą korzystać z wielu zmiennych.

Tabela danych może wyglądać tak:

lub tak:

Tabele danych są szczególnie przydatne, gdy kroki wymagają wielu zmiennych, a także są łatwiejsze do odczytania niż wtedy, gdy każda wartość jest zapisana wewnątrz kroku.  

Praca z tabelami danych i zarysem scenariusza 

Tabele danych i zarysy scenariuszy mogą również działać razem. Nazwa zmiennej zostanie podana w tabeli danych, a następnie ponownie użyta w tabeli przykładów.

Zalety korzystania z zarysów scenariuszy

Zarysy scenariuszy można interpretować jako „szablon” przypadku testowego. Po zaimplementowaniu w ramach platformy automatyzacji testów wykonują one ten sam scenariusz z różnymi zestawami danych.

Zaletą jest mniejsza liczba wierszy Gherkina i mniej powtórzeń. Oznacza to, że za każdym razem, gdy konieczna jest zmiana we wspólnym scenariuszu, można ją wprowadzić tylko raz, a zmiana zostanie zastosowana do wszystkich kombinacji danych testowych.

Kolejną zaletą zarysów scenariuszy jest możliwość zwiększenia zakresu testów przy minimalnym nakładzie pracy. Aby dodać nowy test, należy dodać nowy wiersz przykładu.

Najlepsze praktyki dotyczące pisania zarysów scenariuszy

• Uwzględniaj rzeczywiste dane: Zespół rzadziej przeoczy sytuacje brzegowe lub ukryte informacje, gdy wykorzystuje rzeczywiste przypadki użycia do zrozumienia zachowania.
• Komunikuj cel za pomocą terminologii biznesowej, aby nietechniczni i techniczni interesariusze zespołu mogli lepiej się wzajemnie rozumieć.
• Wyjaśniaj swoją intencję, a nie sposób jej implementacji; objaśnienia kroków powinny być w minimalnym stopniu techniczne. Powinny skupiać się bardziej na funkcjach systemu niż na jego działaniu
• Zachowuj tylko to, co niezbędne: Aby scenariusz był angażujący dla wszystkich uczestników, nie przepełniaj go niepotrzebnymi krokami.

Najważniejsze wnioski

Cucumber to świetne narzędzie współpracy między osobami nietechnicznymi, programistami i testerami. Jest to narzędzie BDD, które zapewnia pisemne specyfikacje i może być używane podczas testowania. Można napisać wiele scenariuszy, aby zademonstrować różne wymagania.

Dobrym pomysłem jest używanie zarysu scenariusza z odrębnymi zestawami wartości dostarczanymi za pośrednictwem tabeli przykładów, gdy występują sytuacje, w których scenariusze mają te same kroki, ale wymagają różnych wartości danych wejściowych lub wyjściowych.

Zapisz się do newslettera The CTO Club, aby uzyskać więcej informacji.