Testy automatyczne przy użyciu SpecFlow, Selenium WebDriver i C# (część I)

Przeczytaj artykuł nt. testów automatycznych przy użyciu SpecFlow, Selenium WebDriver i C#

Cześć! Jestem Michał, od kilku lat pracuję jako programista testów. W serii artykułów pokażę Ci, jak pisać testy automatyczne przy użyciu: frameworka SpecFlow+ Selenium WebDriver + C#.

Dla kogo seria artykułów?

• dla osób, które nie miały okazji pracować ze SpecFlow, a zastanawiają się nad użyciem tego frameworka w swojej firmie.
• dla osób, które chcą rozpocząć swoją przygodę z automatyzacją.

Czego dowiesz się z tego wpisu?

W pierwszym artykule skupię się głównie na teorii, która stanowi podstawę wiedzy na temat testów automatycznych dla platformy.NET.

Dowiesz się:

• czym jest SpecFlow
• jak stworzyć projekt w VS
• poznasz pojęcia wykorzystywane w pisaniu testów, w metodologii BDD
• zainstalujesz Visual Studio Community 2017
• zainstalujesz R# (jest to narzędzie wykorzystywane w firmach komercyjnie (nie jest niezbędne, ale będzie pomocne). Posiada dobrą integrację z testami.
• dodasz paczki NuGet’owe.

Zanim zaczniesz:

Przydadzą Ci się podstawy programowania w C# - skupiamy się bowiem na C# (SpecFlow jest frameworkiem, który dedykowany jest na platformie.NET).

Jeżeli znasz inny język programowania np. Java - sugeruję sprawdzić dowolny kurs C# i zobaczyć, że różnice są głównie w składni. Programowanie warto bowiem rozumieć jako umiejętność, a języki programowania jako narzędzia, których łatwiej nam jest się uczyć, gdy programowaliśmy już w innym.

Na jakiej stronie będziemy tworzyć testy?

Jestem zwolennikiem praktyki.  Stworzyłem dedykowanego bloga, dla którego będziemy tworzyć realne przypadki testowe, które następnie będziemy automatyzować. Link do bloga:  https://courseofautomationtesting.wordpress.com/

Okej. Zaczynamy od wyjaśnienia kilku przydatnych pojęć:

Czym jest SpecFlow?

SpecFlow to najpopularniejszy framework BDD zaimplementowany dla platformy.NET.; stworzony przez Gaspar’a Nagy. Nagy przy jego tworzeniu, inspirował się znanym frameworkiem BDD -  Cucumberem. Aktualnie, obie firmy (twórcy Cucumber i SpecFlow) współpracują w rozwijaniu społeczności skupionej wokół BDD.

SpecFlow rozwijany jest nie tylko przez firmę Gaspar’a Nagy (TechTalk Software Support), ale także społeczność, która jednoczy się poprzez ulepszanie SpecFlow’a (zgłasza błędy, poprawia je na GitHubie oraz proponuje nowe funkcje).

Swoją drogą, jeśli kiedyś będziesz mieć problem związany ze SpecFlowe’em, a przeszukanie Internetu nic nie da, polecam zapytać na GitHubie - prawdopodobnie znajdzie się tam ktoś, kto będzie w stanie pomóc.

Oczywiście firma Gaspar’a ma swój produkt: SpecRun+, który jest komercyjnym dodatkiem pozwalającym uruchamiać testy SpecFlow’a. Nie jest on jednak niezbędny. Istnieją inne frameworki, które są bezpłatne i wspierają SpecFlow (XUnit oraz NUnit).

Czym jest BDD?

BDD – jest to odpowiedź na integrację pomiędzy biznesem a programistami. Wymagania biznesowe są formułowane jasno dla obu stron. Tworzymy kod z perspektywy użytkowników tego oprogramowania.

Źródło: https://cucumber.io/blog/2014/03/03/the-worlds-most-misunderstood-collaboration-tool

Czym jest Gherkin?

Gherkin - to swego rodzaju język, dzięki któremu możemy komunikować się zarówno z biznesem jak i z osobą techniczną. Wykorzystywany jest w BDD do tworzenia scenariuszy.

Dzięki niemu można realizować dwa cele: testy automatyczne jako dokumentacja oraz posiadanie wykonywalnych testów. Czemu jako dokumentacja? Jeżeli testy są utrzymywane i aktualizowane, mogą przedstawiać obecną wersję systemu lepiej niż spisane przypadki testowe, które również trzeba aktualizować, ale nie zawsze o tym pamiętamy. Po uruchomieniu testów od razu dostajemy informację, czy nasza aplikacja pokrywa się z tym, co nasz test automatyczny testuje. Każdy krok „pod spodem” zawiera implementacje w C#.

Przykład prostego testu: 

Jak wygląda podstawowa składnia Gherkina?

Jak każdy język, również Gherkin ma swoją składnię. Poszczególne kroki (steps) w SpecFlow zaczynają się od słów kluczowych.

Given

Stan systemu, który mamy zastany, czyli np. „I’m on home page as user” Jesteśmy na stronie home page z pozycji user’a.

When

Kiedy? Czyli kiedy dana akcja jest spodziewana. „I enter to first post”, w sytuacji gdy znajdujemy się w treści posta.

Then

Rezultat - „I expect to see title post as „First Post”"- Spodziewamy się, że dany post będzie miał taki tytuł „First title”

Dodatkowe słowa kluczowe  (W każdym wpisie będę dodawał kolejne, które powiązane są ze SpecFlow).

Feature

Struktura, w której umieszczamy scenariusze testowe powiązane z danym testowanym obszarem systemu (Featurem). Każdy feature w SpecFlow jako plik posiada: NazwaPliku.feature.  W feature umieszczamy nasz feature, które mają określone scenariusze.

Feature: Nazwa feature, który testujemy.

Scenario

Jest to słowo, od którego zaczynamy każdy scenariusz w SpecFlow.

Plusy i minusy stosowania języka Gherkin

Plusem — jeżeli dobrze będziemy pisać testy będzie możliwość zrozumienia systemu przez osoby postronne. Słyszałem o sytuacjach, gdzie testy były dokumentacją dla nowych pracowników, bo były tak dobrze napisane i stanowiły dobry samouczek na temat możliwości systemu.

Minusy - zgadzam się z wieloma osobami, że jeżeli BDD ma być tylko dla nas, osób tworzących ten kod, to rzeczywiście jest to niepotrzebna warstwa abstrakcji. Jednak jeżeli współpracujecie z biznesem tworząc przypadki czy np. z innymi testerami,  może to być dobra forma komunikacji.

Kto może tworzyć scenariusze BDD?

Spotkałem się z wieloma podejściami zarówno w pisaniu scenariuszy jak i ich implementowaniu. Przybliżę 2 moim zdaniem sensowne podejścia:

• Tester lub QA - pisze tests cases w Gherkinie;  Programista lub Programista Testów - implementuje

To dobre połączenie jeśli programista i tester mają w zwyczaju razem współpracować. Tester może mieć większą wiedzę domenową na temat produktu, więc gdy programista nie zna jakiegoś obszaru, tester może mu pomóc.

Poza tym tests cases powinny być na tyle zrozumiałe, że programista poradzi sobie, nawet jeżeli danego dnia tester będzie nieobecny.

Dobrym rozwiązaniem może być wdrażanie testera przez programistę do pisania kodu;  może to być czasochłonne, ale wszystko zależy od zaangażowania obu osób. W tym podejściu Tester / QA stanowi rolę konsultanta - może pomóc w doborze sensownych przypadków testowych i ułatwić programiście wejście w automatyzację.

• Programista testów jako dedykowany programista, który skupia się na wycinku, jakim jest testowanie automatyczne

W firmie gdzie obecnie pracuję (WhatClinic.com) właśnie takie podejście stosujemy. Ja jestem odpowiedzialny za testy automatyczne i za opiekę nad nimi. Współpracuję również z osobami, które mają wiedzę biznesową, o tym jak użytkownicy używają naszego systemu i które przypadki testowe warto pokryć testami automatycznymi.

To podejście ma kilka plusów:

jedna osoba jest odpowiedzialna za testy — jest to bardzo ważne — gdy nie mamy wydzielonej osoby bardzo często w organizacjach testy zaczynają być "spychane" na drugi plan, aż w końcu umierają śmiercią naturalną, bo inne rzeczy nabywają ważniejszy priorytet.

Angażujemy programistów zainteresowanych tematem — mamy osoby, które interesowały się tematem testów automatycznych. Zaangażowaliśmy ich do przeprowadzania Code Review  (to ważne, aby programiści robiący Code Review mieli wiedzę z framework’u, którego używamy).

W praktyce wygląda to tak, że umieszczam swój kod razem z przypadkami testowymi w Code Review, który następnie sprawdza dwóch programistów.

 Nie wiesz czym jest Code Review?  Z angielskiego jest to „przegląd kodu”. Kod, który został napisany jest brany do oceny przez innych programistów. Dzięki temu cały zespół uczy się czegoś nowego, bo każdy robi CR każdemu. Więc jeżeli ktoś lepiej zna daną technologię, może komuś przedstawić pomysł na użycie jej w lepszy sposób. Code Review to bardzo dobra praktyka, która pozwala unikać błędów i spojrzeć na swój kod z dystansu.

Przed Code Review dobry pomysłem jest również wdrożenie narzędzia do statycznej analizy kodu np. SonarQube, który jest darmowy dla większości popularnych języków programowania.

Znasz już podstawowe pojęcia. Zabieramy się zatem za instalację Visual Studio oraz R#

• Udajemy się na stronę: https://www.visualstudio.com/ - rejestrujemy się lub logujemy (jeżeli mamy konto live).
• Klikamy pobierz VS 2017 Community.
• Po pobraniu instalujemy.
• Po instalacji Visual Studio – pobieramy R# ze strony: https://www.jetbrains.com/resharper/, instalujemy.

R# to dodatek do Visual Studio, który pozwala nam tworzyć kod szybciej i zawiera dobre wsparcie dla testów uruchamianych, z pomocą znanych runnerów, takich jak NUnit czy Xunit. W firmach, gdzie stackiem technologicznym jest platforma .NET R# jest standardem więc warto nauczyć się go i czerpać z niego korzyści w szybszym tworzeniu kodu. R# ma wersję trial 30 dniową – po upłynięciu tego okresu staje się płatny. Jednak dla uczniów /studentów oferują program https://www.jetbrains.com/student/).

• Po instalacji  otwieramy Visual Studio. Tam wyskoczy nam pop-up z pytaniem, jaki key scheme chcemy. Ja używam skrótów klawiszowych z InteliJ’a, więc w moich wpisach właśnie tych będę używał.
• Po instalacji R# zostaje nam instalacja SpecFlow: Otwieramy tools -> Extensions - > Szukamy SpecFlow
• Klikamy zainstaluj - > Zamykamy Visual Studio. SpecFlow instaluje się.
• Po skończonej instalacji możemy przejść do tworzenia projektu testów.
• Otwieramy Visual Studio.
• Klikamy New Project tworzymy projekt -> Library -> Zaznaczamy Source Control (GIT)).

W tym wpisie nie będzie nam to potrzebne, ale przyda się w przyszłości, gdy dodamy nasz kod do repozytorium kodu.

• Dodajemy katalogi do projektu, aby stworzyć taką strukturę w projekcie, która ułatwi nam utrzymywanie porządku w solucji w dłuższej perspektywie niż wolno umieszczone pliki.
• Dziś tworzymy katalogi:
  • Feature - gdzie będziemy umieszczać nasze feature’ry
  • Steps - gdzie będziemy umieszczać kroki (Steps) do naszego projektu.
  • Settings - gdzie umieścimy klasę, która będzie Hookiem dla naszego projektu
• Teraz przechodzimy do dodania potrzebnych NuGet packages.

Czym są NuGet packages? Paczki są kodem, który ułatwia nam tworzenie aplikacji. NuGet jest managerem tych paczek. Pozwala m.in. szukać, pobierać i usuwać z projektu paczki, które mamy.

• Aby pracować z Selenium WebDriver oraz SpecFlow potrzebujemy pobrać:
  • Selenium WebDriver
  • SpecFlow
  • ChromeDriver
• Poza Selenium WebDriver’em oraz SpecFlow potrzebujemy jakiegoś Test Runnera.

Czym jest Test Runner? Jest to program, który pozwala nam w projekcie lub poza nim na uruchamianie testów, które z niego korzystają. Mogą to być testy jednostkowe, integracyjne, czy akceptacyjne. W tej serii skupiamy się na testach akceptacyjnych.

• Dwoma najbardziej popularnymi Test Runnerami jest XUnit oraz NUnit. Nie ma wielkich różnic pomiędzy tymi dwoma jedynie kosmetyczne różnice w składni. Wybieramy zatem NUnita. Nasze pierwsze testy będziemy realizować na ChromeDriverze.

Czym jest ChromeDriver?  ChromeDriver – jeden z dostępnych driverów. Najpopularniejsi providerzy przeglądarek dostarczają swoje implementacje, które implementują standardy WebDriver'a możliwe do zastosowania przez nas w testach automatycznych.

Innymi dość dobrze rozwijającymi klientami są:

Firefox - rozwija się szybko; ma wysoki procent rynku przeglądarek internetowych.

Microsoft Edge - driver, dla którego przyjemnie tworzy się przypadki testowe. Jednym z plusów jest darmowe testowanie automatyczne w chmurze za pomocą BrowserStacka (wspiernego przez Microsoft).

Możemy również wysyłać nasze testy na inne przeglądarki np. Safari za pomocą Selenium Grida.

Przechodzimy do instalacji potrzebnych paczek

• Przechodzimy do VS 2017.
• Klikamy prawy przycisk myszy na nazwę projektu, którą mamy.
• Klikamy "Manage NuGet packages".
• Naszym oczom ukazuje się poniższy ekran.

Wpisujemy wszystkie potrzebny paczki i pobieramy je. SpecFlow, ChromeDriver, Selenium WebDriver.

Podsumowanie

Dzisiejszym wpisem rozpoczęliśmy serię „SpecFlow + Selenium WebDriver”. Dowiedzieliśmy się jak zainstalowć NuGet packages, czym jest VS oraz czym jest SpecFlow.

W następnym wpisie dowiesz się m.in.:

• jak stworzyć pierwszy test automatyczny w SpecFlow?
• jak tworzyć kroki testów wraz z implementacją?
• jak debugować nasze testy?

Zadanie domowe:

• zainstaluj VS oraz dodaj SpecFlow do Visual Studio.
• dodaj potrzebne paczki przez NuGet'a

Zachęcam do komentowania i dzielenia się ze znajomymi pierwszy wpisem kursu.

Na kolejny wpis zapraszamy na: https://testuj.pl/blog/testy-automatyczne-przy-uzyciu-specflow-selenium-webdriver-c-czesc-2/