Łukasz Orzechowski

Gherkin Guru

Automatyzacja testów

© Łukasz Orzechowski, 2025

Na wszystkich etapach procesu wytwarzania oprogramowania konieczna jest kontrola i zapewnienie jakości, realizowane poprzez rozbudowany proces testowania. Zazwyczaj testowaniem zajmują się dedykowane zespoły testerskie.

Z tej książki dowiesz się, jak stworzyć podstawowe testy automatyczne. Wykorzystasz też wiedzę o BDD i język Gherkin do zarządzania projektem i estymacji.

ISBN 978-83-8414-237-0

Książka powstała w inteligentnym systemie wydawniczym Ridero

Spis treści

1. Gherkin Guru

2. Behave Driven Development

3. Page Object Pattern

4. Wybór języka programowania

5. Gherkin

6. Selenium

7. Behave

8. PyCharm

9. PhantomJS

10. Instalacja i konfiguracja środowisk i narzędzi

11. Struktura frameworka (POP)

1. Hybrydowa z użyciem Python i Behave

12. Pierwsze skrypty testowe

13. Samodzielne raportowanie błędów

14. Konfiguracja PhantomJS

15. Tagi w scenariuszach

16. Uruchomienie skryptów

17. Adaptacja dla dowolnego testowanego systemu

18. Użycie narzędzi CI

19. Zebranie rezultatów testów

20. Zmiana języka programowania

21. Estymacja i planowanie z użyciem Gherkin

22. Bibliografia

23. Indeks odnośników

Tytułem wstępu

Na wszystkich etapach procesu wytwarzania oprogramowania konieczna jest kontrola i zapewnienie jakości, realizowane poprzez rozbudowany proces testowania. Zazwyczaj testowaniem zajmują się dedykowane zespoły testerskie. Często w metodykach zwinnych członek zespołu testerskiego wchodzi także w skład zespołu projektowego, na bieżąco monitorując sytuację w projekcie i postępy programistów, czuwając nad właściwym zapewnieniem jakości aplikacji z punktu widzenia użytkownika końcowego.[1]

Zespołom programistycznym zaleca się tworzenie testów jednostkowych na wczesnym etapie tworzenia oprogramowania, zapewniających jak największe pokrycie kodu.[2]

Jednak śledząc sytuację rynkową, te procesy nadal nie są wystarczające dla zapewnienia satysfakcjonującego dla potencjalnego klienta poziomu jakości. Klienci biznesowi oczekują oprogramowania pozbawionego błędów funkcjonalnych i graficznych na poziomie pokrycia niemal stu procent. Wszystkie użyte w procesie tworzenia oprogramowania procesy nie są w stanie zapewnić takiego pokrycia. Niestety, coraz częściej dochodzi do sytuacji, w których całym ciężarem obarczany jest tester, jako jedno z ostatnich ogniw weryfikacji oprogramowania przed dostarczeniem wersji dla klienta końcowego.[3]

Na tym etapie należy zdać sobie sprawę z faktu, że żadna technika, metodyka, żaden, nawet dokładnie zaplanowany i poddany kontroli proces, nie uwolni oprogramowania od wszystkich błędów. Jako zespół projektowy, uczestnicy procesu mogą jedynie wdrażać rozwiązania, zmniejszające potencjalne ryzyko do minimum.

Jednym z takich rozwiązań jest automatyzacja testów po stronie zespołu zapewnienia jakości lub zespołu testerskiego (często mylnie oba te stanowiska są łączone z punktu widzenia definicji i odpowiedzialności na danym stanowisku).[4]

Automatyzacja, jako jeden z etapów procesu wytwarzania oprogramowania oczywiście również nie zapewnia stuprocentowego pokrycia kodu aplikacji i uwolnienia go od błędów. Jednak jest przy tym elementem który, jeżeli dobrze zaprojektowany, może znacznie odciążyć zespół projektowy i częściowo przerzucić odpowiedzialność na procesy, stojące po stronie maszyny. Integracja z narzędziami i procesami CI zapewnia kontrolę błędów na poziomie budowania aplikacji, tj. przetwarzania dostarczonego przez programistów kodu na kod zrozumiały dla maszyny w sposób ciągły i zautomatyzowany. Niniejsze rozwiązanie, dopasowane do potrzeb zespołu projektowego na podstawie wieloletnich doświadczeń jest elastyczne i może zostać wdrożone w dowolnym projekcie biznesowym.[5]

Na przestrzeni lat i rozwoju metodyk zarządzania projektami ewoluowały również różnorodne podejścia do testów automatycznych. Największym problemem, z którym borykają się zespoły projektowe, jak również firmy informatyczne, jest brak jednoznacznego narzędzia, gwarantującego skalowalność do każdej z metodyk oraz języków programowania, stosowanych w tych firmach. Problem ten jest z reguły dystrybuowany na zespoły testerskie lub programistyczne, tym samym przerzucając odpowiedzialność za rzetelne i stuprocentowe pokrycie kodu testami.[6]

Jak wiadomo, testy same w sobie nie stanowią o niezawodnym działaniu aplikacji, a procent pokrycia kodu skryptami nie jest wyznacznikiem jakości. Przykładowo, system może być pokryty w 90% skryptami testowymi, to jednak nie zapewnia zespołu testerskiego ani też klienta o tym, że aplikacja pozbawiona jest błędów. Nie da się bowiem żadnego programu przetestować w 100%, nie da się także przewidzieć wszystkich możliwych scenariuszy użytkownika.

Jednym ze sposobów jest wspomniany już Gherkin, język dla scenariuszy testowych, który przy współpracy z BDD daje możliwość zachowawczego projektowania przypadków testowych oraz samych funkcjonalności systemu.[7] Jednakże to nadal nie rozwiązuje problemu. Klienci potrzebują działającego, gotowego rozwiązania, w zasadzie od zaraz. W większości przypadków klienta nie stać na szkolenie od podstaw zespołu specjalistów do spraw automatyzacji, tym bardziej w tym jednym, konkretnym języku aplikacji, w którym powstaje dany projekt. Brak skalowalności większości rozwiązań implikowałby konieczność nauki każdego z języków programowania dla projektu, a co za tym idzie coraz większy narzut kosztowy w miarę rozwoju technologii bez rozsądnej stopy zwrotu z inwestycji.

W kolejnych rozdziałach przedstawiam opis podejść i narzędzi, których użyjemy do stworzenia naszego frameworka testów automatycznych. Jeżeli jesteś już z nimi zaznajomiony, proponuję, abyś przeszedł do części praktycznej, w którym przejdziemy przez kolejne etapy instalacji i konfiguracji środowisk, od pierwszej do ostatniej linii kodu, aż po uruchomienie skryptów testowych.

Zachęcam przy tym do zapoznania się z pozycjami z bibliografii, które na pewno rozwiną wiedzę na temat metodyk, jak i przedstawionych rozwiązań.

[1] Adam Roman, Testowanie i jakość oprogramowania, PWN, 2015, s. 651

[2] Kent Beck, TDD sztuka tworzenia dobrego kodu, HELION, 2014, s.10

[3] Alan Page, The A Word. Under the Covers of Test Automation, LeanPub, 2013, s.5

[4] James Shore, Shane Warden, Agile Development — Filozofia Programowania Zwinnego, HELION, 2012, s.78

[5] Za: Kanglin Li, Mengqui Wu, Effective GUI Test Automation, SYBEX, 2005, s.20

[6] Alan Page, The A Word. Under the Covers of Test Automation, LeanPub, 2013, s.29

[7] John Ferguson Smart, BDD w działaniu. Sterowanie zachowaniem w rozwoju aplikacji, HELION, 2016, s. 60—65

Behave Driven Development

Behave Driven Development jako jedna z technik wytwarzania oprogramowania poprzez definiowanie zachowań staje się coraz bardziej popularnym podejściem. Daje ono szeroki wachlarz rozwoju procesów. Z roku na rok przybywa też narzędzi, wspomagających BDD.

Pojęcie po raz pierwszy zdefiniowane przez Dana Northa łączy testy jednostkowe tworzone w podejściu Test Driven Development (TDD) i testy akceptacyjne User Acceptance Tests (UAT). Celem jest poznanie potrzeb i oczekiwań użytkownika docelowego w rozumieniu klienta i stworzenie oprogramowania, które te oczekiwania spełnia.[1]

W podejściu BDD testy akceptacyjne pisane są najczęściej z użyciem języka Gherkin, w oparciu o historyjki użytkownika, skupiające się na roli, funkcji i wynikających z nich korzyści w rozumieniu funkcjonalności.

Parafrazując Janet Gregory, takie działanie ma na celu wytworzenie oprogramowania dopasowanego do potrzeb użytkownika już w początkowej fazie procesu wytwarzania oprogramowania. Cel ten sam w sobie nie jest łatwy do osiągnięcia, jeżeli nawet nie niemożliwy, jednakże takie podejście zapewnia zminimalizowanie wystąpienia błędów w późniejszych fazach.[2]

Jak dodaje Liz Keogh, pojęcie „zachowanie” (behave) pozwala na eksplorację niejednoznacznych obszarów aplikacji (jak również przypadków brzegowych), których nie da się opisać zero-jedynkowo (jest lub nie ma), poprzez odwołanie się do kontekstu użytkownika. Tym samym pozwala na jednoznaczną definicję przypadków testowych dla niejednoznacznych wymagań klienta.[3]

[1] Kent Beck, TDD sztuka tworzenia dobrego kodu, HELION, 2014, s.8

[2] PapryQArz, L. Pietrucha, BDD w praktyce: http://papryqarz.org/wp-content/uploads/2015/03/PapryQArz_1_Lpietrucha_BDD_w_praktyce.pdf, odczyt z dn. 3.04.2017

[3] Liz Keogh, BDD: https://lizkeogh.com/behaviour-driven-development/, odczyt z dn. 4.12.2017

Page Object Pattern

Podczas pisania testów stron internetowych należy odnosić się bezpośrednio do konkretnych elementów tych stron, w celu otwarcia danego linku, czy weryfikacji wyświetlania elementów. Podczas projektowania skryptów, które działają bezpośrednio na kodzie HTML testowanej aplikacji, narażone są one na zmiany występujące po stronie UI. Zastosowanie Page Object Pattern wspomaga proces tworzenia takich przypadków. Ukrywa obiekt strony, nadpisuje kod HTML lub jego fragment tzw. API specyficznym dla aplikacji, umożliwiając manipulację takimi elementami bez potrzeby bezpośrednich odwołań do kodu HTML.[1]

Obiekty strony kierują się podstawową zasadą, by klient oprogramowania „robił” wszystko i „widział” wszystko, co człowiek (użytkownik). Zapewnia on również interfejs, który jest łatwy w programowaniu i ukrywaniu podstawowych widżetów i elementów w oknie aplikacji. Przykładowo, aby uzyskać dostęp do pola tekstowego, konieczne są metody typu „accessor”, przyjmujące i zwracające ciąg znaków. Elementy wyboru powinny używać zmiennych typu boolean, a przyciski muszą być reprezentowane nazwami metod zorientowanych na ich działanie. W założeniu obiekt strony powinien otoczyć całą tę mechanikę odpowiedzialną za znalezienie, identyfikację i manipulowanie danymi po stronie GUI. Zmiana konkretnej akcji kontroli elementu nie powinna wymusić zmiany interfejsu strony.[2]

Mimo użycia terminu „strona”, obiekty strony nie powinny być budowane dla każdej ze stron testowanej lub tworzonej aplikacji, a dla kluczowych jej elementów. Przykładowo, strona będąca galerią zdjęć, zawierająca kilka albumów zawierałaby obiekt z listą albumów. Te obiekty zawierałyby w sobie kilka obiektów po stronie albumu. Istniałby także obiekt strony nagłówka i obiekt strony stopki. Takie skomplikowanie hierarchii obiektów interfejsu użytkownika występuje tylko w celu ustrukturyzowania interfejsu użytkownika. Obiekty będące komponentami tej hierarchii nie powinny być ujawniane przez obiekty stron. Podstawową zasadą jest takie modelowanie struktury na stronie, która ma sens dla użytkownika aplikacji. W przypadku akcji nawigowania do innej strony obiekt początkowy powinien zwrócić kolejny (nowy) obiekt dla otwartej strony.

Podsumowując, operacje na obiektach strony powinny zwracać podstawowe typy zmiennych (string, data, boolean) lub inne obiekty stron.[3]

Obiekty stron w rozumieniu Page Object Pattern są często używane podczas testowania, ale nie powinny zawierać elementów weryfikacyjnych same w sobie. Są one odpowiedzialne jedynie za zapewnienie dostępu do niższej warstwy kodu. To po stronie testów leży zapewnienie logiki weryfikacyjnej.[4]

Ten sam schemat ma zastosowanie nie tylko w przypadku stron internetowych czy logiki testów. Jak twierdzi Mark Fowler, spotkał się on z pozytywnym zaadaptowaniem obiektów stron w efektywnym ukrywaniu detali Java Swing UI. Jest także przekonany o powszechnym zastosowaniu Page Object Pattern w wielu innych rozwiązaniach i frameworkach bazujących na UI.

Problemy ze współbieżnością to kolejny temat, w którym można zastosować obiekty stron, chociażby poprzez ukrywanie asynchronii w operacjach asynchronicznych, które nie są widoczne dla użytkownika jako asynchroniczne. Możliwa jest także enkapsulacja wątków w interfejsie użytkownika, gdzie konieczne jest alokowanie zachowania między interfejsem użytkownika i wątkami zależnymi.[5]

Obiekty stron to modelowy przykład enkapsulacji — ukrywają szczegóły struktury UI i odniesienia do innych komponentów strony lub testów. Dobrą manierą projektowania jest odnajdywanie takich sytuacji w miarę rozwoju kodu. Podobnie jak w przypadku enkapsulacji, daje to dwie niezaprzeczalne korzyści. Jedną z nich jest ograniczanie logiki manipulującej interfejsem użytkownika w jednym miejscu poprzez jej modyfikację bez wpływu na inne składniki systemu. Drugą z korzyści jest łatwiejsze zrozumienie kodu klienta lub testów z uwagi na intencje, by skupić się na funkcji kod lub testu a nie detalach interfejsu użytkownika.[6]

[1] Martin Fowler, Page Object, 10.09.2013: https://martinfowler.com/bliki/PageObject.html, odczyt z dn. 12.06.2017

[2] Selenium Framework, What is Page Object: http://www.seleniumframework.com/python-frameworks/what-is-page-object/, odczyt z dn. 4.04.2017

[3] Being Agile, Pete Hodgson, Assertions in Page Objects: http://blog.thepete.net/blog/2013/09/13/assertions-in-page-objects/, odczyt z dn. 4.04.2017

[4] Martin Fowler, Page Object, 10.09.2013; https://martinfowler.com/bliki/PageObject.html, odczyt z dn. 12.06.2017

[5] Testuj.pl, Page Object Pattern dla dużej aplikacji webowej: https://www.youtube.com/watch?v=fSZrL8lt8u8, odczyt z dn. 2.12.2017

[6] Martin Fowler, Page Object, 10.09.2013; https://martinfowler.com/bliki/PageObject.html, odczyt z dn. 15.06.2017

Wybór języka programowania

W celu prawidłowej implementacji frameworka konieczny jest wybór właściwego języka programowania. O ile skalowane rozwiązanie można zaimplementować dla dowolnego języka programowania (wobec wielu opinii najlepiej takiego, w jakim stworzony został cały testowany projekt) ważne jest, aby prace nad rozwiązaniem rozpocząć od łatwego w nauce i intuicyjnego języka, na tyle elastycznego, aby późniejszy rozwój za pomocą innych języków był dość intuicyjny.

W przypadku popularnego podejścia tworzenia przypadków testowych w języku projektu, na każdym etapie w przypadku problemów z dalszym rozwojem skryptów, łatwo jest uzyskać niezbędną wiedzę od programisty zaangażowanego w powstawanie aplikacji. Jednakże brak znajomości tego języka programowania implikować może dalsze problemy po stronie testera, mające wpływ na cały zespół — konieczna jest dodatkowa nauka danego języka, powstają opóźnienia w dostarczeniu kodu z uwagi na zaangażowanie zespołu w naukę i natłok pytań ze strony zespołu testerskiego. To może prowadzić do porażki całego przedsięwzięcia, a w konsekwencji do znacznych strat, głównie finansowych.

Jednym z najprostszych rozwiązań jest identyfikacja potrzeb zespołu i klienta. Dostosowanie języka programowania do strony, która będzie właścicielem skryptów i będzie odpowiadała za ich dalszy rozwój, jest najodpowiedniejszym podejściem.

Dla zespołu testerskiego, tworzącego i utrzymującego testy automatyczne dobrym podejściem jest użycie języka programowania, w którym napisane są testy dla innych projektów, które tworzy firma zatrudniająca. Testy tworzone z pomocą Selenium nie wymagają tego samego języka do ich tworzenia, co testowana aplikacja.[1]

Dla zespołu programistycznego warto zastanowić się nad perspektywą utrzymania kodu, to implikuje z kolei prosty wniosek, aby testy tworzyć w języku, w którym tworzona jest testowana aplikacja.

Decyzja wyboru języka programowania testów automatycznych nie jest łatwa. Obarczona jest dalszymi konsekwencjami, które warto przewidzieć i omówić przed przystąpieniem do właściwych prac, w taki sposób, aby spełnić oczekiwania zarówno zespołu projektowego, jak i klienta. Wszystko to zapewni późniejszy sukces i ułatwi dalsze prace.

W niniejszym projekcie został użyty język Python, jako wyjściowa dla dalszych prac z uwagi na łatwość nauki przez osoby początkujące (późniejsze zaznajomienie się z innymi językami programowania także nie powinno nastręczać problemów), dostępność rozwiązań, a także fakt znajomości tego języka programowania przez autora.

[1] Dave Haeffner, Selenium Guidebook, Python Edition, Dave Haeffner, version 1.1.0, 2016, s.5

Gherkin

Gherkin jest językiem, który rozumieją interpretery Cucumber, Behave i wiele innych. Umożliwia opisywanie zachowań aplikacji bez zagłębiania się w szczegóły, dotyczące implementacji kodu. To sprawia, że jest czytelny, zrozumiały dla biznesu, specyficzny dla domeny. Zapewnia wsparcie dla dwóch dziedzin — dokumentacji projektowej wszelkiego typu oraz automatyzacji testów.[1]

Gramatyka specyficzna dla tego języka zdefiniowana jest w gramatyce Treetop, która jest częścią bazy kodu Cucumber. Gramatyka ta istnieje w wielu odmianach, specyficznych dla wielu języków mówionych. Oznacza to już ponad 60 języków używanych na całym świecie. Umożliwia to więc swobodny rozwój spisywanych scenariuszy w dowolnym języku, którym posługuje się zespół projektowy lub klient biznesowy.[2]

Składnia języka Gherkin podobna jest do składni Python oraz YAML, opiera się na użyciu wcięć (akapitów) i znaków nowej linii dla zdefiniowania struktury. Znaki nowej linii definiują koniec danego kroku scenariusza.[3]

Zakłada się użycie składni anglojęzycznej w prezentowanym projekcie.

Struktura pojedynczego pliku feature (zawierającego opisy scenariuszy dla danej funkcjonalności) przedstawia się więc następująco:[4]

Feature: Zdanie opisujące w sposób zwięzły funkcjonalność

In order to przedstawienie wartości biznesowej

As an rola użytkownika systemu

I want to uzyskanie rezultatów, które prowadzą do określonego celu (realizacji wyników funkcjonalności)

Scenario: Przykładowa, możliwa do określenia, sytuacja biznesowa

Given pewien wstępny warunek

And dodatkowy warunek wstępny

When pewna akcja wykonana przez użytkownika (kliknij, przejdź do strony, itp.)

And kolejna akcja wykonana przez użytkownika

And kolejna akcja wykonana przez użytkownika (ich ilość może być dowolna)

Then osiągnięcie pewnego testowalnego wyniku (w części tej następuje sprawdzenie poprawności wykonania scenariuszy z części „When” przy założeniu wstępnych warunków części „Given”)

And weryfikacja kolejnego zdarzenia

Scenario: Inna sytuacja biznesowa

Treść scenariusza

Możliwe jest użycie mechanizmu komentarzy w postaci linii, rozpoczynających się znakiem „#”, zawierających dowolną ilość tekstu komentarza.

Interpreter na podstawie struktury dzieli na wejściu zawartość tekstową na funkcjonalności, scenariusze oraz ich składowe — poszczególne kroki testów. Po uruchomieniu zestawu testów tekst, znajdujący się po słowie kluczowym „Given”, „And”, „When”, „Then” dla poszczególnych scenariuszy dopasowywany jest do bloku kodu wykonawczego nazywanego „definicjami kroku”, znajdującymi się w plikach „steps”.[5]

[1] Behat, Gherkin Syntax: http://docs.behat.org/en/v2.5/guides/1.gherkin.html, odczyt z dn. 18.07.2017

[2] Za: Dan North, What is in a story: https://dannorth.net/whats-in-a-story/, odczyt z dn. 18.07.2017 oraz Bitprohet, Specification-style nosetests output for Python: https://github.com/bitprophet/spec, odczyt z dn. 11.09.2017

[3] Behat, Gherkin syntax: http://docs.behat.org/en/v2.5/guides/1.gherkin.html, odczyt z dn. 15.06.2017

[4] .Selenium Framework, Behave Project Structure: http://www.seleniumframework.com/python-frameworks/behave-project-structure/, odczyt z dn. 19.05.2017

[5] Selenium Framework, Behave Project Structure: http://www.seleniumframework.com/python-frameworks/behave-project-structure/, odczyt z dn. 20.06.2017

Selenium

Selenium jest jednym z popularnych, jeżeli nie najpopularniejszym rozwiązaniem dla testów automatycznych w ujęciu testowania UI aplikacji web.[1]

Zapewnia narzędzia do nagrywania i odtwarzania skryptów w sposób prosty i zrozumiały, bez konieczności posiadania zaawansowanej wiedzy z dziedziny programowania. Prosty eksport tak przygotowanych skryptów daje duże możliwości adaptacyjne do dowolnej platformy czy też języka programowania dzięki pseudojęzykowi Selenese. Języki programowania, wspierane przez Selenium: C#, Groovy, Java, Perl, PHP, Python, Ruby, czy scala, przewyższają dalece innych konkurentów rynkowych, nic więc dziwnego, że duże korporacje, tworzące oprogramowanie dla szerokiej gamy konsumentów indywidualnych i biznesowych, wybierają właśnie to narzędzie.[2]

Testy przygotowane w Selenium, czy to za pomocą narzędzi nagrywających, czy za pomocą języka skryptowego, mogą zostać w łatwy sposób uruchomione w wielu popularnych, nowoczesnych przeglądarkach na urządzeniach stacjonarnych i przenośnych, dzięki czemu idealnie wpasowuje się w ideę niniejszego projektu.

Selenium przygotowane zostało z myślą o systemach Windows, Linux, OS X, nie jest więc uzależnione od platformy stosowanej przez producenta oprogramowania.[3]

Jednocześnie Selenium jest narzędziem w pełni darmowym, rozpowszechnianym na licencji open-source Apache 2.0.[4]

[1] Dave Haeffner, Practical tips and tricks for Selenium Test automation: http://www.slideshare.net/Applitools/practical-tips-tricks-for-selenium-test-automation-dave-haeffner, odczyt z dn. 20.09.2017

[2] Dave Haeffner, How to use selenium successfully: http://www.slideshare.net/tourdedave/how-to-use-selenium-successfully, odczyt z dn. 20.09.2017

[3] Selenium, What is selenium: http://www.seleniumhq.org/, odczyt z dn. 21.09.2017

[4] Selenium, License: http://www.seleniumhq.org/about/license.jsp, odczyt z dn. 21.09.2017

Behave

Behave jest interpreterem języka Gherkin dla Behave Driven Development, przygotowanym z myślą o języku Python.[1]

Behave wykorzystuje testy pisane językiem naturalnym, użytkowym, z myślą o łatwej kooperacji pomiędzy programistami, testerami i biznesem, niekoniecznie zorientowanym na języki programistyczne w projekcie informatycznym.

Na rynku istnieje szereg podobnych narzędzi i interpreterów, dedykowanych konkretnym językom programowania i frameworka. Poniżej przedstawiono porównanie narzędzi dedykowanych językowi Python, z zaznaczeniem plusów i minusów w odniesieniu do użytego w projekcie Behave.

Jednym z narzędzi jest popularny dla Ruby i Java Cucumber.[2] Może on być także użyty do uruchomienia testów napisanych w języku Python. Używa biblioteki „rubypython” do uruchomienia interpretera Python wewnątrz procesów Ruby. Biblioteka ta została porzucona jakiś czas temu i nie posiada już wsparcia, dlatego też Cucumber używany jest częściej z językiem Java i Ruby, aniżeli z Pythonem.[3] Oczywistą decyzją jest użycie narzędzia w pełni wspieranego przez Python, napisanego z użyciem tego języka. Rozwiązanie to nie zostało więc użyte do stworzenia niniejszego projektu.

Kolejnym interpreterem języka Gherkin jest Lettuce. Jest on podobny do narzędzia Behave jako jedno z rozwiązań przepisanych bezpośrednio z Cucumber. Podstawowa różnica pomiędzy Lettuce i Behave to użycie jedynie dekoratora @step, zamiast wielu dekoratorów typu @given, @when, @then, @step dla zróżnicowanych kroków testów.[4]

Lettuce nie wspiera także opcji tagowania, tak potrzebnej w tworzonym projekcie frameworka testów automatycznych.[5] Kod definicji kroków może być przechowywany gdziekolwiek w folderze „features” — daje to nieco więcej swobody, niż w przypadku Behave, jednak poniekąd zaprzecza idei użycia Page Object Pattern w konkretnym schemacie. Innym problemem w Lettuce jest brak czyszczenia zmiennej globalnej „world” pomiędzy kolejnymi wykonaniami scenariuszy typu „outline”, przez co konieczne jest dodatkowe obsłużenie tego typu sytuacji. Behave czyści ten rodzaj zmiennych domyślnie pomiędzy każdym scenariuszem.[6]

Na rynku istnieje także wtyczka Freshen. Jednak z uwagi na pojawiające się problemy, takie jak:[7]

— Integracja z „nose runner” powodująca trudności w debugowaniu wyjątków porażki w testach,

— Wyniki wykonania skryptów, obsługiwane przez „nose” nie są czytelne, implikuje to konieczność instalacji dodatkowych wtyczek

— Zmienne kontekstowe nie są tak elastyczne, jak w przypadku Behave — zmiana ich nazwy czy przenoszenie wymaga dodatkowych nakładów pracy

— Nazwy kroków muszą być unikatowe, nawet jeżeli używają dekoratorów różnego typu kroków

— Brak obsługi i kontroli Before / After scenario — jedynie Before — powoduje konieczność użycia operacji „atexit” lub „teardown” pozostawia skrypty bez pełnej kontroli

Z uwagi na powyższe problemy, Lettuce nie jest brany pod uwagę jako narzędzie, które mogłoby zostać użyte w niniejszym projekcie.

[1] Python Hosted, Welcome to Behave: http://pythonhosted.org/behave/, odczyt z dn. 12.08.2017

[2] Cucumber, Getting started with Cucumber: https://cucumber.io/docs, odczyt z dn. 12.08.2017

[3] Python Hosted, Welcome to Behave: http://pythonhosted.org/behave/, odczyt z dn. 14.08.2017

[4] Lettuce, introduction: http://lettuce.it/tutorial/simple.html, odczyt z dn. 14.08.2017

[5] Python Hosted, Comparison With Other Tools: https://pythonhosted.org/behave/comparison.html, odczyt z dn. 4.12.2017

[6] Ibidem, https://pythonhosted.org/behave/comparison.html, odczyt z dn. 4.12.2017

[7] QA Testing Tools, Freshen: http://www.qatestingtools.com/testing-tool/freshen, odczyt z dn. 20.08.2017

PyCharm

Jako zintegrowane środowisko programistyczne dedykowane językowi Python, PyCharm oferuje edycję i analizę kodu źródłowego, moduł debugowania kodu w formie graficznej, moduł uruchomieniowy dla testów jednostkowych (i automatycznych) oraz zintegrowaną kontrolę wersji.

PyCharm działa na wielu platformach. Zapewnia wsparcie dla systemów Windows, Linux oraz OSX. Wydawany jest zarówno w wersji Community Edition (darmowej), jak i w wersji Professional.[1] W projekcie użyto wersji Professional ze względu na pełne wsparcie wtyczek, koniecznych do jego realizacji.

Zestaw funkcji edytora PyCharm spełnia oczekiwania, stawiane narzędziom wspierającym pisanie kodu programów.[2] PyCharm zawiera w sobie edytor w sposób inteligentny podświetlający składnię kodu, co ułatwia jego uzupełnianie, pisanie i lokalizację ew. błędów popełnionych przez programistę. Funkcja weryfikacji błędów składni na bieżąco podczas pisania kodu wraz z graficznym debuggerem Python i integracją z systemami kontroli wersji zapewnia płynne i stosunkowo łatwe zarządzanie kodem testów.[3]

[1] JetBrains, PyCharm — Editions Comparison Matrix: https://www.jetbrains.com/pycharm/features/editions_comparison_matrix.html, odczyt z dn. 23.07.2017

[2] JetBrains, PyCharm: https://www.jetbrains.com/pycharm/, odczyt z dn. 19.07.2017

[3] W3big, Python IDE: http://www.w3big.com/pl/python/python-ide.html, odczyt z dn. 14.08.2017

PhantomJS

PhantomJS to skryptowa, pozbawiona warstwy GUI (graficznego interfejsu użytkownika) przeglądarka internetowa, używana do automatyzacji aplikacji typu web.[1]

Opiera się ona na WebKit, dzięki czemu testowane aplikacje uruchamiane są w podobnym środowisku jak Safari i Google Chrome.[2]

[1] Envato Tuts +, Denis Sokolov, Headless Functional Testing with Selenium and PhantomJS: https://code.tutsplus.com/tutorials/headless-functional-testing-with-selenium-and-phantomjs--net-30545, odczyt z dn. 14.08.2017

[2] Real Python, Headless Selenium Testing With Python and PhantomJS: https://realpython.com/blog/python/headless-selenium-testing-with-python-and-phantomjs/, odczyt z dn. 23.07.2017

[3] PhantomJS, FAQ: http://phantomjs.org/faq.html, odczyt z dn. 12.09.2017

[4] Google Developers, Getting Started with Headless Chrome: https://developers.google.com/web/updates/2017/04/headless-chrome, odczyt z dn. 13.09.2017

[1] Podstawy Informatyki, Podstawy obsługi systemów UNIX/Linux: http://pkosla.kis.p.lodz.pl/fl/pi_lab2.htm, odczyt z dn. 11.10.2017

[2] Seleniumframework, Python Basic, First Project: http://www.seleniumframework.com/python-basic/first-project/, odczyt z dn. 18.11.2017

[3] Seleniumframework, Python Basic, What Is Python: http://www.seleniumframework.com/python-basic/what-is-python/, odczyt z dn. 18.11.2017

[4] Linuxiarze.pl, Instalacja programów w Debianie i Ubuntu — apt i dpkg: https://linuxiarze.pl/pakiety_debian1/, odczyt z dn. 4.12.2017

[5] Github Gist, Julionc, How to install PhantomJS on Ubuntu: https://gist.github.com/julionc/7476620, odczyt z dn. 12.11.2017

[6] Github, Joke2k, Faker: https://github.com/joke2k/faker, odczyt z dn. 2.08.2017

[7] iPython, Introducing IPython: http://ipython.readthedocs.io/en/stable/interactive/tutorial.html, odczyt z dn. 5.04.2017

[8] JetBrains PyCharm Blog, Dmitry Filippov, Feature Spotlight: Behavior-Driven Development in PyCharm: https://blog.jetbrains.com/pycharm/2014/09/feature-spotlight-behavior-driven-development-in-pycharm/, odczyt z dn. 10.11.2017

[9] JetBrains, PyCharm Docs, Run/Debug Configuration: Behave: https://www.jetbrains.com/help/pycharm/run-debug-configuration-behave.html, odczyt z dn. 2.05.2017

[10] JetBrains, Configuring Python Interpreter: https://www.jetbrains.com/help/pycharm/configuring-python-interpreter.html, odczyt z dn. 17.04.2017

[1] Seleniumframework, Python Frameworks, Behave Project Structure: http://www.seleniumframework.com/python-frameworks/behave-project-structure/, odczyt z dn. 21.05.2017

[2] Seleniumframework, Python Frameworks, First Behave Gherkin: http://www.seleniumframework.com/python-basic/first-behave-gherkin/, odczyt z dn. 22.05.2017

[3] Seleniumframework, Archive Test Results: http://www.seleniumframework.com/basic-tutorial/archive-test-results/, odczyt z dn. 17.04.2017

[4] Za: StackOverflow, Setting and reading environment variables: https://stackoverflow.com/questions/5971635/setting-reading-environment-variables, odczyt z dn. 10.11.2017

[5] Scrolltest: Step by Step Mobile App Testing with Appium in Python: http://scrolltest.com/2015/05/02/step-by-step-mobile-app-testing-with-appium-in-python/, odczyt z dn. 4.12.2017

[6] Python For Beginners, How to use the Random Module in Python: http://www.pythonforbeginners.com/random/how-to-use-the-random-module-in-python, odczyt z dn. 18.11.2017

[7] Seleniumframework, What Is Base Page: http://www.seleniumframework.com/python-frameworks/what-is-base-page/, odczyt z dn. 14.06.2017

[8] Learn Python, Klasy i obiekty: http://www.learnpython.org/pl/Klasy_i_obiekty, odczyt z dn. 6.12.2017

[9] Dave Haeffner, Selenium Guidebook, Python Edition, Dave Haeffner, version 1.1.0, 2016, s.17

[10] ToolsQA, Selenium WebDriver Wait Commands: http://toolsqa.com/selenium-webdriver/wait-commands/, odczyt z dn. 22.07.2017

[11] Za: Code Clinic, Javascript, Importing data with AJAX: https://www.lynda.com/JavaScript-tutorials/Importing-data-AJAX/369707/384717-4.html, odczyt z dn. 1.09.2017

[12] Za: informIT, David M. Beazley, Operators and Expressions in Python: http://www.informit.com/articles/article.aspx?p=459269&seqNum=7, odczyt z dn. 10.09.2017

[13] Dave Haeffner, Elemental Selenium, Implicit vs. Explicit Waits: elementalselenium.com,, odczyt z dn. 22.07.2017

[14] Dave Haeffner, Elemental Selenium, Implicit vs. Explicit Waits: elementalselenium.com,, odczyt z dn. 22.07.2017

[15] Za: Guru99, Keyboard & Mouse Event using Action Class in Selenium Webdriver: https://www.guru99.com/keyboard-mouse-events-files-webdriver.html, odczyt z dn. 14.11.2017

[16] Dave Haeffner, Selenium Guidebook, Python Edition, Dave Haeffner, version 1.1.0, 2016, s.13

[17] Za: DevNami, Get text of element in Selenium Python WebDriver: https://www.youtube.com/watch?v=zqz80o92OzQ, odczyt z dn. 3.10.2017

[18] Za: Learn Automation, How to Scroll into view in Selenium Webdriver: http://learn-automation.com/how-to-scroll-into-view-in-selenium-webdriver/, odczyt z dn. 18.07.2017

[19] Za: Nadim Saker, How to refresh or reload a page in selenium webdriver: http://nadimsaker.blogspot.com/2014/09/how-to-refresh-or-reload-page-in.html, odczyt z dn. 18.07.2017 oraz: DevNami, Python Selenium Webdriver Refresh a Webpage: https://www.youtube.com/watch?v=9vkbyVOTEbI, odczyt z dn. 9.11.2017

[20] PythonHosted, Behave API Reference: https://pythonhosted.org/behave/api.html, odczyt z dn. 3.10.2017

[21] PythonHosted, Behave API Reference, Before All: https://pythonhosted.org/behave/api.html, odczyt z dn. 17.04.2017

[22] Za: StackOverflow, Passing command line argument to python-behave: https://stackoverflow.com/questions/22528535/passing-command-line-argument-to-python-behave, odczyt z dn. 10.09.2017

[23] PythonHosted, Behave API Reference, Before Feature: https://pythonhosted.org/behave/api.html, odczyt z dn. 2.12.2017

[24] PythonHosted, Behave API Reference, Before Scenario: https://pythonhosted.org/behave/api.html, odczyt z dn. 20.05.2017

[25] PythonHosted, Behave API Reference, After Scenario: https://pythonhosted.org/behave/api.html, odczyt z dn. 11.08.2017

[26] PythonHosted, Behave API Reference, After Feature: https://pythonhosted.org/behave/api.html, odczyt z dn. 3.04.2017

[27] PythonHosted, Behave API Reference, After All: https://pythonhosted.org/behave/api.html, odczyt z dn. 23.03.2017

[28] Selenium Python, Locating Elements: http://selenium-python.readthedocs.io/locating-elements.html, odczyt z dn. 11.10.2017 oraz Tech Beamers, Harsh S., 8 Ways To Use Locators For Selenium Testing: http://www.techbeamers.com/use-locators-selenium/, odczyt z dn. 5.12.2017

[29] Mike Grouchy, Be Pythonic: __init__.py: http://mikegrouchy.com/blog/2012/05/be-pythonic-__init__py.html, odczyt z dn. 2.11.2017

[30] Patrz: pliki projektu

[31] Roman Pichler, 10 tips for writing good user stories: http://www.romanpichler.com/blog/10-tips-writing-good-user-stories/, odczyt z dn. 3.12.2017

[32] Behat, Writing features — gherkin language: http://docs.behat.org/en/v2.5/guides/1.gherkin.html, odczyt z dn. 2.12.2017

[33] Arturas Smorgun, Tagging features in Gherkin and Behat: https://arturas.smorgun.com/2014/02/13/tagging-features-in-gherkin-and-behat.html, odczyt z dn. 3.10.2017

[34] Automation Panda, BDD01, Writing good Gherkin: https://automationpanda.com/2017/01/30/bdd-101-writing-good-gherkin/, odczyt z dn. 23.07.2017

[35] Relish, Scenario outlines: https://relishapp.com/cucumber/cucumber/docs/gherkin/scenario-outlines, odczyt z dn. 4.08.2017

[36] Cucumber, Gherkin Reference: https://cucumber.io/docs/reference, odczyt z dn. 11.05.2017

[1] Behave Example, Using the Step Matchers: https://jenisys.github.io/behave.example/step_matcher/using_matchers.html, odczyt z dn. 21.09.2017

[2] Semaphore, Phillip Johnson, Getting Started with Behavior Testing in Python with Behave: https://semaphoreci.com/community/tutorials/getting-started-with-behavior-testing-in-python-with-behave, odczyt z dn. 23.09.2017

[3] PythonHosted, Behave Tutorial: https://pythonhosted.org/behave/tutorial.html, odczyt z dn. 10.09.2017

[4] JetBrains, PyCharm, Creating Examples Table in Scenario Outline: https://www.jetbrains.com/help/ruby/creating-examples-table-in-scenario-outline.html, odczyt z dn. 10.09.2017 oraz StackOverflow, Selecting a word using starting and ending regex: https://stackoverflow.com/questions/33254626/selecting-a-word-using-starting-and-ending-regex, odczyt z dn. 12.05.2017

[1] Patrz też: JetBrains, PyCharm, Run/Debug Configuration: Behave: https://www.jetbrains.com/help/pycharm/run-debug-configuration-behave.html, odczyt z dn. 8.08.2017

[1] Za: PythonHosted, Feature Testing Setup: https://pythonhosted.org/behave/gherkin.html, odczyt z dn. 8.08.2017

[1] Arturas Smorgun, Tagging features in Gherkin and Behat: https://arturas.smorgun.com/2014/02/13/tagging-features-in-gherkin-and-behat.html, odczyt z dn. 3.10.2017

[2] Ibidem: https://arturas.smorgun.com/2014/02/13/tagging-features-in-gherkin-and-behat.html, odczyt z dn. 23.10.2017

[1] JetBrains, PyCharm, BDD Testing Framework: https://www.jetbrains.com/help/pycharm/bdd-testing-framework.html, odczyt z dn. 11.08.2017

[2] PythonHosted, Using behave: https://pythonhosted.org/behave/behave.html, odczyt z dn. 11.08.2017

[1] Za: TestWarez, Piotr Baran, Testowanie aplikacji mobilnych w chmurze — amazon device ffarm vs test object: http://www.testwarez.pl/testowanie-aplikacji-mobilnych-w-chmurze-amazon-device-farm-vs-test-object/, odczyt z dn. 2.12.2017

[1] GitLab, GitLab Continuous Integration & Deployment: https://about.gitlab.com/features/gitlab-ci-cd/, odczyt z dn. 3.12.2017

[2] Docker Docs, Best practices for writing Dockerfiles: https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/, odczyt z dn. 4.12.2017

[3] GitLab Documentation, GitLab Continuous Integration (GitLab CI), Configuration of your jobs with. gitlab-ci. yml: https://docs.gitlab.com/ee/ci/yaml/, odczyt z dn. 16.08.2017

[4] /dev/blog, Docker-compose budowanie środowiska: https://devblog.it/docker-compose-budowanie-srodowiska/, odczyt z dn. 19.08.2017

[5] GitLab Documentation, Testing standards and style guidelines, Frontend testing standards and style guidelines: https://docs.gitlab.com/ce/development/testing_guide/frontend_testing.html, odczyt z dn. 23.08.2017

[1] GitLab Documentation, GitLab Continuous Integration (GitLab CI), Configuration of your jobs with. gitlab-ci. yml: https://docs.gitlab.com/ee/ci/yaml/, odczyt z dn. 5.09.2017

[2] GitLab Documentation, Jobs artifacts administration: https://docs.gitlab.com/ce/administration/job_artifacts.html, odczyt z dn. 5.09.2017

[3] Za: Dr inż. Andrzej Grosser, Testowanie oprogramowania, http://icis.pcz.pl/~agrosser/wtest.pdf, odczyt z dn. 4.08.2017

[1] PythonHosted, Comparison With Other Tools: https://pythonhosted.org/behave/comparison.html, odczyt z dn. 15.09.2017

[2] Na miękko, Wieża Babel. Skąd tyle języków programowania?: http://namiekko.pl/2014/12/27/wieza-babel-skad-tyle-jezykow-programowania-czesc-1-z-3/, odczyt z dn. 22.11.2017

[1] Xebia, Kishen Simbhoedatpanday, Example Mapping — Steering the conversation: http://blog.xebia.com/example-mapping-steering-the-conversation/, odczyt z dn. 24.11.2017

Koniec darmowego fragmentu książki.

Zachęcamy do zakupu pełnej wersji.