Testowanie za pomocą narzędzia Cypress

Spis treści

1. Czym jest Cypress- narzędzie do automatycznego testowania?
2. Środowisko Windows
3. Interfejs graficzny Cypress

Istnieje ogromna różnorodność narzędzi do testowania oprogramowania mobilnego. Wybór zależy w dużej mierze od poziomu doświadczenia testerów, biegłości w automatyzacji i znajomości dostępnych rozwiązań. Do tej pory koncentrowaliśmy się na Appium do automatyzacji testów i działało to całkiem dobrze dla nas. Okazało się dobrym narzędziem do zastosowania w ciągłej integracji w połączeniu z Jenkins i Fastlane

Czym jest Cypress – narzędzie do automatycznego testowania?

Cypress to gotowe narzędzie które jest gotowe do pracy od momentu instalacji. Selenium WB oferuje więcej możliwości personalizacji, ale osiągnięcie podobnego stopnia responsywności i szybkości działania możliwe jest po konfiguracji przez doświadczonego w tym środowisku. Krzywa wejścia dla osoby bez doświadczenia jest łagodniejsza dla Cypressa. 

W przypadku wyboru narzędzia z którym będziemy pracować dużą rolę odgrywa wsparcie twórców i społeczności. W tym względzie Cypressowi nie można niczego zarzucić. Aktualizowany i utrzymywany jest cały czas a dzięki dobrej dokumentacji i możliwości wgrywania gotowych rozszerzeń bądź pisania własnych – mocno podatny na konfigurację.Użyty Javascript także pomaga w dostosowaniu środowiska pod własne potrzeby.

Stawiając pierwsze kroki wspomagani będziemy przez dokładne dokładne komendy oraz filmy z konfiguracji i pierwszych testów. Pomocne także okazują się repozytoria z przykładowymi projektami które podejmują popularne problemy. 

Środowisko Windows

Wymagania: NodeJS i Cypress

Instalacja

Ściągnij i zainstaluj NodeJS

Przy pomocy konsoli sprawdź, czy NodeJS został poprawnie zainstalowany. Poniższa instrukcja powinna dać odpowiedź informującą o zainstalowanej wersji:

npm -v

Podaj ścieżkę do folderu gdzie zainstalowany ma być Cypress

cd /your/project/path

npm install cypress –save-dev

Zgodnie z dokumentacją dostępną na stronie Cypress powinien być poprawnie zainstalowany oraz skonfigurowany. Wpisujemy więc komendę

cd node_modules/.bin/ 

cypress open

Program uruchomi się, ale jeśli używamy Windowsa najprawdopodobniej napotkamy na taki błąd

 Rozwiązaniem problemu jest utworzenie pliku  package.json w głównym katalogu projektu

{
  "scripts": {
    "test": "cypress open"
  }
}

Otwórz konsolę i wprowadź ścieżkę do projektu, następnie uruchom testy

Jeśli chcesz korzystać z interfejsu graficznego najprostrzym rozwiązaniem na Windowsie jest utworzenie pliku który będzie skrótem do uruchamiania danego projektu. 

2a Tworzymy plik nowy plik tekstowy. Dla tego celu użyłem systemowej aplikacji Notatnik.

cd C:\cypress-projectX

npm run test

Następnie plik zapisujemy z rozszerzeniem “.bat”

Gdzie pierwsza linijka to komenda przejścia do katalogu “cd” oraz ścieżka lokalizacji folderu projektu podczas instalacji Cypressa. Dzięki komendzie z drugiej linii uruchomi się launcher poszczególnych testów które przygotowaliśmy w dla Cypressa.

Przykład okna konsoli dla projektu roboczo nazwanego cypress-s po uruchomieniu wcześniej utworzonego pliku wsadowego

Po instalacji dostępne są przykładowe testy. Jeśli nie są nam potrzebne możemy śmiało je usunąć. Cypress automatycznie wczytuje foldery oraz pliki znajdujące się w folderze integration. Oprogramowanie monitoruje dodawane pliki – nie musisz resetować okna głównego by nowo dodane testy były widoczne. 

Aby uruchomić test kliknij na niego dwukrotnie lub skorzystaj z opcji umieszczonej w prawym górnym rogu – run all tests.

Jak więc wygląda struktura testów?

Po raz kolejny na początkowym etapie bardzo pomocna jest dokumentacja. Powyższy kod dobrze zobrazowuje co jest widoczne po wykonaniu testu.

Plik testu oczywiście nie musi się ograniczać do instrukcji zapisanej w definicji fukcji “it”. Pomocne okazuje się stosowanie specjalnych funkcji jak “beforeEach” wykonujące instrukcje jednorazowo przed scenariuszami w danym pliku czy “before” które zawarty kod będzie wykonywać przed każdym scenariuszem. Pamiętajmy, że korzystamy tutaj z JavScriptu, więc dołączanie fukcji czy zmiennych zdefiniowanych w plikach zewnętrznych jest jak najbardziej możliwe. 

Jeśli chodzi o konfigurację Cypress prócz możliwości typowych dla tego języka (JS) oferuje wiele ułatwień:

• cypress.js – plik konfiguracyjny – zmieniać możemy bazowy adres testowanej strony, ignorowane błędy HTTP czy maksymalny czas oczekiwania na odpowiedź
• cypress.env – domyślny plik do gromadzenia zmiennych używanych w projekcie. Jego przewaga nad ręcznie dodanymi plikami jest taka, że jest automatycznie dodawany do każdego testu i traktowany priorytetowo
• plugins – plik gdzie możemy dodawać wtyczki wspierane przez społeczność
• commands – miejsce gdzie możemy zapisać napisane przez nas specjalistyczne komendy. 
• i wiele innych – po raz kolejny odsyłam do dokumentacji

Interfejs graficzny Cypress

Tryb graficzny wykonywania testów znacznie ułatwia pracę nad nimi i kontrolę poprawności działania. W tym trybie Cypress po wykonaniu testu pozwala na cofnięcie się do dowolnego jego kroku. Wystarczy wybrać interesujący nas krok z listy po lewej stronie by została wyświetlona strona sprzed wybranej akcji. Pomaga to znacząco w debugowaniu testów. 

Jeśli wybraliśmy przeglądarkę Chrome do wykonania testu klikając F12 uruchamiamy konsolę. Dzięki wspomnianej wyżej funkcji możemy sprawdzić czy np przeglądarka znalazła interesującą nas grupę elementów i czy ilość odpowiada spodziewanej.

Po kliknięciu w symbol oka w konsoli wylistowane zostają szukane przez nas elementy

Oczywiście w tym momencie możemy wybrać konkretny element i zbadać jego szczegóły.

Weźmy za przykład aplikację która wymaga od użytkownika logowania. Jeśli chcemy sprawdzić także kolejne jej aspekty mamy do wyboru kilka opcji

1. Logować się za każdym razem manualnie
2. Podać aplikacji gotowe ciastko/token który umożliwi stronie rozpoznanie użytkownika jako zalogowanego

Pierwsza opcja sprawdzi się w przypadku gdy np nie mamy dostępu do backendu, nie zależy nam na szybkości wykonywania testów. Zdecydowanie lepszą opcją jest rozwiązanie wymagające podania ręcznie aktywnego tokenu użytkownika. Mamy pewność, że w przypadku zmiany ekranu logowania/tymczasowych problemów z nim związanych nadal będzie możliwe wykonanie dalszych testów aplikacji. W omawianym przykładzie strona korzysta z autentykacji w standardzie Auth0. Poniżej kod testu logowania w taki sposób:

describe('login using token/cookie', () => {

       it('should successfully log into our app', () => {
         cy.login()
           .then(() => {
             window.location.replace("https://lab4.itcraft.pl:XYZ/web");
             cy.visit('web')
           })
           debugger
       });
})

Oraz definicja funkcji login()

Cypress.Commands.add('login', () => {
   Cypress.log({
     name: 'loginViaAuth0'
   })

return cy.request({
   method: 'POST',
           url: '/admin-api/login',
           headers: {
               "Content-Type": "application/json"
           },
           body: {
               username: Cypress.env('correctUsername'),
               password: Cypress.env('correctPassword'),
           },
        })
        .then((resp) => {
           document.cookie = `AuthUser=${resp.body.accessToken}`
        })
})

 Zapytanie było sprawdzone wcześniej w Postmanie. Wykonując kod widać, że serwer zwraca ciastko z aktywnym tokenem – też sprawdzane później ręcznie. Problem pozostaje jeden – aplikacja nie chce przejść do kolejnego ekranu. Zostaje na podstronie logowania.

To jedna z pytań na które nie znalazłem odpowiedzi. W konsoli nie logów potwierdzających nieprawidłowe działanie. Mimo tego, zarówno na przeglądarce Electron jak i Chrome rezultat jest taki sam. Wiem jednak, że w przypadku prostszych serwisów – lub bardziej doświadczonych programistów – problem ten nie powinien występować. Mockowanie danych to potężne narzędzie i używane z rozmysłem potrafi zaoszczędzić dużo czasu na planowaniu skomplikowanych nie-kolidujących się testów czy czyszczeniu bazy danych przed każdym uruchomieniem. 

Kolejną kwestią specyficzną dla Cypressa może na początku wydawać się brak możliwości kontynuowania wykonywania jednego przypadku testowego w momencie, gdy otwierane jest nowe okno przeglądarki. Tetsy wykonywane są tylko w oknie, w którym zostały na początku uruchomione. Wymusza to na testerze przygotowywanie takich przypadków, które nie będą od siebie zależne – czyli tak, aby niepowodzenie wykonania jednego testu nie przekreślało z góry wykonania kolejnych. Problem ominąć można sprawdzając, czy odnośnik prowadzi do szukanej podstrony i tą testować w oddzielnym scenariuszu.