Specflow czyli BDD w praktyce

Dzisiaj pokażę w praktyce w jaki sposób zbieram wymagania korzystając z narzędzia Specflow.
Na początku przypomnę nasze historie użtkownika.
Potem skonfigurujemy dodatek Specflow Visual Studio.
Na końcu pokażę jak wygląda język Gherkin i zaimplementujemy pierwszą historię użytkownika US1.

Oto lista funkcjonalności, które będę implementował w aplikacji Perfect Life:

US1: Jako użytkownik aplikacji mobilnej chcę ekran logowania aby mieć możliwość zapisywania swoich postępów
US2: Jako użytkownik aplikacji mobilnej chcę mieć kalkulator wskaźnika BMI aby móc mierzyć poziom swojej kondycji
US3: Jako użytkownik aplikacji mobilnej chcę widzieć wykresy aby móc wizualnie interpretować swoje postępy
US4: Jako użytkownik aplikacji mobilnej chcę mieć możliwość rozwiązania quizu, żeby zbadać wskaźnik Body Age
US5: Jako użytkownik aplikacji mobilnej chcę pobierać pliki PDF aby mieć dostęp do planów dietetycznych
US6: Jako administrator aplikacji chcę zapisywać dane telemetryczne aby móc analizować zmianę liczby użytkowników
US7: Jako użytkownik aplikacji mobilnej chcę mieć możliwość analizy własnego zdjęcia, aby móc obiektywnie sprawdzić na ile lat wyglądam

Zakładam, że korzystamy Visual Studio 2017. Oto instrukcja obsługi krok po kroku, która zaprowadzi nas do tego czym jest BDD(Behaviour Driven Design):

1) Instalujemy odpowiedni plugin, który możemy pobrać ze strony:
https://marketplace.visualstudio.com/items?itemName=TechTalkSpecFlowTeam.SpecFlowforVisualStudio2015

Plugin nazywa się Specflow i został stworzony przez firmę Techtalk. Obserwuję ten produkt od kilku lat i za każdym razem kiedy pojawia się nowa wersja Visual Studio (2012, 2013, 2015, 2017) to Techtalk wydaje kolejną edycję swojego pluginu. Dodać należy, że Specflow jest oficjalną implementacją standardu Cucumber dla języka C#. Oznacza to, że możemy korzystać z języka Gherkin do tworzenia scenariuszy testowych. Co więcej nasze scenariusze będą wyglądały tak samo w Specflow jak w innych implementacjach dla języka PHP, albo Javy. Zatem łatwo przenieść scenariusze do innych projektów.

2) Tworzymy nowy projekt testowy w Visual Studio.
3) Do projektu dodajemy nowy plik z rozszerzeniem .feature. Oczywiście plugin Specflow zasugeruje nam odpowiedni plik.
Dzięki rozszerzeniu specflow w Visual Studio mamy dostęp do nowych rodzajów plików. Ważne: Jeśli nie zainstalujemy dodatku Specflow, to nie będzie ich tutaj.



4) Tworzymy scenariusz testowy wewnątrz właśnie utworzonego pliku.
Zwykle scenariusze piszę w języku angielskim, ale tym razem wykorzystam język polski na potrzeby projektu Perfect Life.
Już jakiś czas temu odkryłem, że we frameworku Behat (implementacja standardu Cucumber dla języka PHP) istnieje możliwość tworzenia scenariuszy w językach innych niż angielski(w tym język polski). Przykładowo aby aktywować język polski wystarczy dodać na górze pliku ze scenariuszem linijkę:

# language: pl

. Jako że dodałem tę linijkę to podświetlanie składni w Visual Studio działa wyśmienicie. Oto rezultat:



Póki co mamy dwa scenariusze. Za chwile powiem do czego się nam ode przydadzą.

5) Tworzymy kroki testowe w języku C#. Ogromna zaleta BDD - możemy zamienić naszą dokumentację opracowaną w języku Gherkin na wykonywalne testy.
My nie będziemy dziś tego robić, bo interesuje nas jedynie dokumentacja. Warto jednak wiedzieć, że możemy zautomatyzować nasze testy za pomocą np. biblioteki webdriver i podłączyć je do naszych scenariuszy.
Kilka lat temu czytałem bloga mojego kolegi Jacka Norberta, który specjalizuje się w tematyce testów automatycznych. Znalazłem tam jedno kluczowe zdanie, które moim zdaniem jest kwintesencją koncepcji BDD. Brzmiało ono mniej więcej tak: "Główną korzyścią ze stosowania Acceptance Test Driven development(lub BDD) nie jest to, że zyskujemy działające testy, ale to, że zastosowana koncepcja poprawia komunikację w zespole programistycznym oraz komunikację z klientem". Miałem szczęście, że przeczytałem to zdanie kilka lat temu. Dzięki temu wiem na czym to wszystko polega i mogę skupić się bardziej na zbieraniu wymagań niż na implementacji samych testów w języku C#, czy PHP.


Wróćmy na chwilę do naszych scenariuszy: Jeden mówi o próbie logowania zakończonej sukcesem, a drugi o tym jak aplikacja powinna zadziałać kiedy użytkownik spróbuje zalogować się do aplikacji korzystając z nieprawidłowych danych. Zastanawiasz się w jaki sposób je teraz wykorzystamy?
Otóż w następnych dwóch tygodniach zaimplementuję te funkcjonalności tak aby teoretycznie mój klient mógł wziąć te scenariusze i zgodnie z nimi wykonać testy akceptacyjne. Dzięki temu, że ja jako programista mam dostęp do tych scenariuszy, wiem kiedy mogę stwierdzić, że funkcjonalność jest skończona a kiedy nie. Generalnie skutki wdrożenia koncepcji BDD w projektach informatycznych są takie, że zespół programistyczny pracuje wydajniej bo wie czego klient będzie od niego oczekiwał. I teraz bardzo ważna rzecz: Scenariusze powinny być uzgodnione z klientem przed każdym sprintem(Najlepiej dodajmy je do naszego dokumentu Definition of Ready). Dzięki temu programiści zaoszczędzą mnóstwo czasu ponieważ nie będą zmuszeni zbierać wymagań w trakcie sprintu. W efekcie zwiększa się ilość pracy jaką jesteśmy w stanie wykonać w trakcie sprintu. Ostatecznym skutkiem będzie to, że klient będzie bardziej zadowolony ponieważ będziemy mogli uzyskać produkt wyższej jakości w krótszym czasie. Tak to działa. Naprawdę warto.

Tak więc jutro zaczynamy sprint numer 1.
Czekajcie na więcej...