Redakcja
Scenariusze BDD tworzą „specyfikację w przykładach” – są to wysokopoziomowe opisy pożądanego zachowania oprogramowania w odpowiedzi na akcje użytkownika. Powinny być w pełni zrozumiałe dla osób nietechnicznych tak, aby mogły stanowić pomost pomiędzy zespołem programistycznym a biznesem. Jeżeli scenariusze są dostarczane przez analityka biznesowego lub powstają jako produkt spotkań „three amigos” (programista – tester – analityk), testerowi automatycznemu pozostaje tylko je zautomatyzować. W praktyce jednak często tester sam musi je napisać – a wówczas czyhają na niego różne pułapki, wynikające z technicznego spojrzenia na funkcjonalności. Jako przykład rozważmy funkcjonalność wyszukiwania na stronie.
Pracę rozpoczynamy od stworzenia historyjki użytkownika, jednej na plik.
As a… I want… So that…
Po chwili refleksji, kto będzie użytkownikiem danej funkcjonalności i jakie korzyści odniesie, jesteśmy w stanie napisać:
So that I am able to find anything that I am interested in.
Dobry początek. Teraz pozostaje tylko wypełnić plik serią scenariuszy, które pozwolą przetestować tak opisaną funkcjonalność.
- Wiele asercji w jednym scenariuszu
Na początek sprawdzamy, jak wyglądają takie scenariusze. Najbardziej widoczną cechą wydaje się to, że składają się z trzech rodzajów kroków – Given, When, Then.
Then…
Stop! Nie do końca o to chodzi. Scenariusz powinien testować jedno zachowanie – jego weryfikacja następuje w kroku „Then”, więc po nim nie powinno już być miejsca na żadne kolejne akcje użytkownika. Może tam się znaleźć najwyżej „And” z asercją sprawdzającą dodatkowy warunek. Testerzy doświadczeni pisaniem innych rodzajów testów mogą odczuwać pokusę, aby podczas jednego przejścia przez daną ścieżkę przetestować tyle, ile się da, ale nie o to chodzi w przypadku BDD. Tutaj należy skoncentrować się na jednym zachowaniu, które chcemy zweryfikować. Im mniej kroków, tym lepiej. Stan aplikacji ustalamy w "Given", "When" określa, co zrobi użytkownik, natomiast "Then" – jak aplikacja ma na to zareagować. W przypadku wyszukiwania przykładowo można napisać:
Then I am given the list of three items named „test”
Przejście do strony wyszukiwania ze strony główniej można w takim przypadku pokryć w osobnym scenariuszu. Kolejność Given – When – Then (Zakładając, że… - Kiedy… - Wtedy…) nie jest przypadkowa i nie wolno jej zaburzać.
- Techniczny opis kroków
Kolejną pokusą jest zbyt techniczny opis kroków. Członkom zespołu programistycznego zdarza się zapomnieć, że używane przez nich na co dzień określenia nie należą do powszechnie stosowanego języka. Warto też mieć na uwadze, że gdyby potencjalny adresat scenariuszy BDD był osobą techniczną i rozumiał kod, scenariusze byłyby niepotrzebne. Unikać zatem należy kroków takich jak na przykład „Then js is executed” czy „Then href is equal to http://test.test”.
- Brak koncentracji na zachowaniu
Nie ma potrzeby zamieszczania dokładnej informacji, których kontrolek użytkownik używa, ponieważ interesuje nas, co robi, a nie – w jaki sposób. Szczegóły techniczne, nazwy przycisków, ich oznaczenia czy symbole mogą się zmieniać – scenariusz skoncentrowany na zachowaniu nie będzie w takim przypadku wymagał modyfikacji. Nawet jeżeli przykładowo wyszukiwanie było dotychczas rozpoczynane klawiszem „Enter”, a po zmianach interfejsu wymaga kliknięcia na przycisk „Szukaj”. W scenariuszu BDD obie wersje wpasują się w krok „When I search for…”.
- Długie scenariusze
Mimo że pamiętamy, iż asercje powinny znajdować się w krokach typu "Then" i że te kroki powinny występować w scenariuszu jako ostatnie, wciąż możemy się pogubić podczas opisywania czynności wykonywanych przez użytkownika. Ryzyko to jest szczególnie wysokie w przypadku złożonych ścieżek, przez które użytkownik musi przejść, aby wywołać testowane zachowanie oprogramowania. W takiej sytuacji warto jest jak najwięcej etapów ukryć w kontekście, czyli "Given" – tak by tylko jedna lub dwie finalne czynności wykonane przez użytkownika wywołały weryfikowane zachowanie. Kroki wykonane w ramach dotarcia do pożądanego stanu wyjściowego można w razie potrzeby przetestować w obrębie innych scenariuszy.
- Zamieszanie z podmiotem
Podczas gdy wielu autorów preferuje pisanie scenariuszy w pierwszej osobie („When I click…”), niektórzy uważają trzecią osobę za bardziej właściwą („Given the customer is on the page…”). Najważniejsze jest jednak, by przyjąć jedną z tych konwencji i konsekwentnie się jej trzymać.
Podsumowując, przed rozpoczęciem pisania dobrze jest się zapoznać się nie tylko z ogólnymi zasadami BDD, ale również z przykładami dobrze napisanych scenariuszy i dobrymi praktykami ich tworzenia. Warto każdorazowo zadać sobie pytanie, czy tak napisany scenariusz oddaje sedno testowanego zachowania oprogramowania i czy byłby zrozumiały dla osoby bez wiedzy technicznej.
Autor: Agata Ostaszewska-Smykała
Źródła i więcej informacji:
https://azevedorafaela.wordpress.com/2017/05/01/bad-practices-when-writing-your-bdd-scenarios/
