Przygoda z Protractorem

Dominika Jedrzejczak
dodane przez: Dominika Jedrzejczak | Marzec 23, 2017

Dawno, dawno temu (no może nie aż tak dawno) poznański oddział Pearson podjął się zadania realizacji dwóch modułów do nowego globalnego projektu NSE. Wydano dekret i po całym mieście rozeszła się wieść, że Pearson poszukuje dzielnych wojowników, którzy sprostają zadaniu. Chętnych było co niemiara, przeprowadzono więc turniej rycerski. W jego wyniku 3 wojownicze księżniczki  i 11 dzielnych wojów rozpoczęło pracę w projekcie…

Czas szybko mija i jak to w życiu bywa wiele się od tego czasu zmieniło. Moja opowieść dotyczyć będzie tylko jednej z tych wielu zmian i zaczyna się w pewien słoneczny poranek, latem 2015 roku. Jak zwykle przyszłam do pracy bardzo wcześnie, by już o poranku zająć się testami. Ze zdziwieniem dostrzegłam naszego front-end dewelopera Michała, który zwykle zaczynał pracę w nieco późniejszych godzinach. Postanowiłam skorzystać z okazji i przedyskutować z nim problemy w automatyzacji, z którymi zmagałam się poprzedniego dnia. Wynikiem tej ciekawej dyskusji była propozycja, żeby zmienić narzędzie do automatyzacji i zacząć pisać testy w Protractorze. I tak to się zaczęło…

Wybór i przygotowanie narzędzia nie jest zadaniem łatwym, toteż postanowiliśmy przedyskutować pomysł w większym gronie i do dyskusji zaprosiliśmy naszego Head of QA Grzegorza. Wynikiem spotkania była lista wymagań jakie postawimy przed nowym rozwiązaniem:

  • scenariusze w języku naturalnym (angielski);
  • wsparcie dla Page Object;
  • rozwiązanie oparte o Selenium;
  • testy uruchamiane na Selenium Grid;
  • testy uruchamiane na wielu przeglądarkach;
  • niezależność od systemu operacyjnego;
  • umożliwienie wsparcia testów przez deweloperów z możliwie najmniejszym progiem wejścia.

Mając już wymagania zajęliśmy się analizą, czy Protractor może spełnić je wszystkie. Minęły dwa miesiące nim udało mi się przygotować taką konfigurację, która spełniałaby minimum naszych wymagań. Postawione przed nami cele udało nam się spełnić dzięki wykorzystaniu następujących modułów nodejs:

Moduł Pełniona funkcja
PROTRACTOR Automatyczna obsługa asynchroniczności Angulara (funkcja waitForAngular)
CUCUMBERJS Scenariusze w języku naturalnym Gherkin
ASTROLABE Page Object dla testów
PROTRACTOR-CUCUMBER

PROTRACTOR-CUCUMBER-FRAMEWORK

Umożliwia połączenie protractora i cucumberjs
CHAI

CHAI-AS-PROMISED

Obsługa asercji
GRUNT-PROTRACTOR-RUNNER Przygotowanie tasków do uruchamiania testów


Kolejnym krokiem było podjęcie decyzji, co do sposobu organizacji kodu testów. Już wcześniej zdecydowaliśmy się na Page Object, który porządkował znaczną część kodu. Pozostały jednak jeszcze inne elementy, które należało zorganizować w logiczną całość. Wynikiem naszych rozważań jest następująca struktura:

Protractor 1

Odpowiednio w poszczególnych sekcjach znajdują się:

  • features – scenariusze Gherkin
  • steps – definicje kroków scenariusza w JS
  • pages – astrolabowe Page Objecty
  • elements – sekcje wyróżnione z Page Object (np. większe bardziej skomplikowane elementy na stronie, elementy wielokrotnie powtarzające się)
  • support – pliki wspierające, czyli:
    • methods – biblioteki zawierające funkcje często wykorzystywane np. operacje i przekształcenia dat, stringów, dodatkowe obliczenia i przekształcenia danych
    • data – pliki json zawierające dane niezbędne do przebiegu testów oraz ich mapowania (np mapowania klas elementów na ich logiczne znaczenie)
    • users – zbiór plików json reprezentujących środowiska i zawierające odpowiednio dane użytkowników
    • photo – pliki graficzne wykorzystywane w testach

Czas mijał, nasze potrzeby i wymagania odnośnie narzędzia rosły. Pierwszą zmianą było przygotowanie przez dwóch kolegów z zespołu – Roberta i Macieja – dodatkowego modułu nodejs grunt-protractor-cucumber-html-report, który służy do generowania raportu html z generowanego przez cucumber json’a z wynikami. Stworzenie i dodanie tego modułu umożliwiło nam graficzne przedstawienie wyników z działania testów automatycznych i prezentację ich zarówno innym członkom zespołu jak i przedstawicielom biznesu. Poniżej screen z fragmentu raportu html z przebiegu testów.

Protractor 2

Chcieliśmy również uczynić uruchamianie testów możliwie łatwym zadaniem, w związku z czym dodaliśmy kolejne moduły nodejs: grunt-selenium-standalone i selenium-webdriver, dzięki nim selenium jest pobierane i uruchamiane automatycznie podczas startu testów. Taką pierwszą podstawową konfigurację znajdziecie tutaj.

Również konfiguracja narzędzia ulegała licznym zmianom. Stały predefiniowany plik konfiguracyjny został zamieniony na szablon, dzięki czemu stało się możliwe dynamiczne generowanie konfiguracji na podstawie parametrów podanych przy uruchomieniu taska gruntowego. W ten sposób skonfigurowano:

  • wybór przeglądarki;
  • wybór środowiska testowego i odpowiadającego mu pliku z bazą użytkowników;
  • wybór sposobu reprezentacji wyników (wynik w konsoli/ raport html);
  • wybór serwera selenium (selenium grid/ selenium lokalne);
  • wybór taga (czyli przypadków testowych do wykonania).

Kolejnym ważnym  krokiem było przygotowania zadania na Jenkins do uruchamiania testów. Dzięki współpracy Oli i Jakuba udało stworzyć się rozwiązanie zapewniające nam codzienną kontrolę przyrostów naszej aplikacji. W  tym celu przygotowane zostało środowisko testowe – budowane codziennie pod koniec dnia z najnowszego kodu, na którym uruchamiane są testy. Dane testowe zapewnia kopia bazy wykonywana przed uruchomieniem automatów i odtwarzana tuż po ich zakończeniu. Dodatkowo powstało zadanie umożliwiające manualne uruchomienie testów na wskazanym przez siebie środowisku. Listę dostępnych parametrów zobaczyć można na poniższym screenie.

Protractor 3

Przed nami jeszcze dużo pracy:

  • przy pisaniu nowych i utrzymaniu istniejących scenariuszy;
  • z rozwiązaniem zależności projektowych (np. integracji z innymi systemami);
  • z udoskonalaniem konfiguracji narzędzia i sposobów zapewniania danych.

W ferworze walki o lepsze i bardziej wydajne testy nie możemy zapominać o tym jak wiele udało nam się już osiągnąć. W związku z czym, kończąc moją opowieść, chciałabym bardzo podziękować wszystkim tym, którzy przyczynili się do tego sukcesu, czy to poprzez pracę nad narzędziem i testami, czy też przejmując codzienne obowiązki umożliwiając innym dodatkową pracę nad zadaniami technicznymi. Dziękuję wszystkim byłym i aktualnym członkom zespołów New Student Experience za to co udało nam się wspólnie osiągnąć, mając jednocześnie nadzieję, że jeszcze wiele wspólnych przygód i sukcesów przed nami. 🙂

Dominika Jedrzejczak

Dominika Jedrzejczak

Senior QA Specialist at Pearson Ioki. Often takes part in knowledge sharing events such as Test Warez, PTaQ, GGC and Test Carrots. Loves dancing, writing poems and Marvel movies. Her motto is "It is never too late to be what you might have been"
Informacja dotycząca plików cookies

Informujemy, iż w celu optymalizacji treści dostępnych w naszym serwisie, dostosowania ich do Państwa indywidualnych potrzeb korzystamy z informacji zapisanych za pomocą plików cookies na urządzeniach końcowych użytkowników. Pliki cookies użytkownik może kontrolować za pomocą ustawień swojej przeglądarki internetowej. Dalsze korzystanie z naszego serwisu internetowego, bez zmiany ustawień przeglądarki internetowej oznacza, iż użytkownik akceptuje stosowanie plików cookies.

Akceptuję