Powrót do strony głównejCypressAnywhere.ioO autorze
Powrót

Mój pierwszy test

Testy automatyczne opisane w tym blogu są zorganizowane w następującej formie:

  1. Przypadków testowych wraz z krokami (w uproszczonej formie)
  2. Linku do miejsca w repozytorium kodu, w którym znajduje się implementacja testów automatycznych
Dzięki temu, lektura oraz nauka, będą przyjemniejsze. W każdym momencie możliwe będzie, ściągnięcie skonfigurowanego projektu Cypress na swój komputer oraz uruchomienie testów lokalnie. Będę również dbała o to, aby przykłady były na bieżąco aktualizowane, gdy właściciel testowanej aplikacji, dokona zmiany niekompatybilnej wstecz.

Kilka słów o automatyzacji testów

Aby prawidłowo przygotować projekt aplikacji webowej do testów automatycznych, podstawą jest oznaczenie elementów w aplikacji, atrybutami dedykowanymi dla testów. Powszechną dobrą praktyką jest, użycie do tego celu atrybutów nazwanych data-* - przykładowo, jeżeli chcemy oznaczyć przycisk, który przeniesie użytkownika na stronę logowania, oznaczamy ten przycisk atrybutem data-test="login-button". Co istotne, developerzy nie powinni nazwy tego atrybutu nigdy zmienić, ponieważ spowoduje to, że testy automatyczne nie znajdą tego przycisku i zwrócą niepowodzenie. Niestety bardzo często, testy automatyczne są w projektach pomijane, dlatego nawet duże projekty, nie są do testowania przygotowane. Da się je pokryć testami, jednak brak dedykowanych atrybutów powoduje, że niekiedy niewielka zmiana wprowadzona przez developerów może spowodować, że testy nie odnajdą oczekiwanego elementu i zwyczajnie przestaną działać. Jeżeli automatyzujesz projekt, który posiada te braki, należy je jak najszybciej wyeliminować. Takie niedociągnięcia, które wymagają poprawy, nazywamy długiem technologicznym. Inną ważną sprawą jest powtarzalność procesu logowania. W każdym przypadku testowym testowanej aplikacji, Cypress będzie uruchamiał przeglądarkę internetową ponownie, czyszcząc jednocześnie wszystkie informacje, w tym informacje o uwierzytelnieniu w aplikacji. Dlatego proces logowania będziemy chcieli powtórzyć, a nasz kod za to odpowiedzialny "reużywać". W Cypress możemy to osiągnąć dodając komendę odpowiedzialną za logowanie do aplikacji w pliku commands.js, znajdującym się w katalogu support.

Pierwszy test na tym blogu...

Na wstępie zaznaczę, że do pierwszych testów, wybrałam formularze logowania, na stronach sklepów internetowych, których jestem użytkownikiem, ale których wcześniej nie testowałam w żaden sposób. Logowanie do aplikacji jest krytycznym punktem testowania. Musimy w bezpieczny sposób przekazać hasło do aplikacji i przekazać innym developerom (tester automatyzujący jest developerem testów automatycznych - programistą testów automatycznych) instrukcję, w jaki sposób mogą hasło do testów przekazać. Cypress umożliwia przekazanie haseł na wiele sposobów - ja wybrałam przekazanie haseł poprzez plik cypress.env.json (szczegóły znajdują się w pliku README.MD), który dodatkowo dodam do pliku .gitignore naszego repozytorium z projektem (więcej o repozytoriach w późniejszych postach). W tym poście skupię się na przypadkach testowych funkcjonalności logowania do następujących aplikacji:

  • Platforma aukcyjna Allegro
  • Sklep internetowy marki odzieżowej Mohito
  • Sklep internetowy marki odzieżowej Reserved

W tym miejscu wyjaśnię znaczenie następujących fraz (funkcji), które występują w moim kodzie: decribe, it, xit

  • describe - w skrócie jest to opis naszego przypadku testowego, jako pierwszy argument przyjmuje nazwę przypadku, jako drugi argument przyjmuje funkcję, którą wykonuje
  • it - jest to opis naszego kroku, jako pierwszy argument przyjmuje nazwę kroku, jako drugi funkcję, którą wykonuje
  • xit - "x" przed "it" powoduje, że krok jest zakomentowany. Komentowanie w programowaniu oznacza "wyłączanie", gdy z jakiegoś powodu, chcemy posiadać ten kod mimo, że nie działa prawidłowo.

1. Przypadek testowy: Funkcjonalność uwierzytelnienia użytkownika w Allegro

Krok 1: Jako istniejący użytkownik loguję się do aplikacji

Krok 2: Jako użytkownik akceptuję Politykę ochrony prywatności

Krok 3: Sprawdzam, czy użytkownik jest zalogowany

Gdy spojrzymy na kod testu, zauważamy od razu, że w przypadku kroków nr 2 oraz nr 3, pojawia się wspomniane wyżej, komentowanie. Przy kroku nr 1 - okno dotyczące akceptacji Polityki prywatności, pojawia się bezpośrednio po wejściu na stronę (funkcja znajduje się w składzie kroku nr 1 - w folderze commands.js). Krok nr 2, który także dotyczy akceptacji Polityki prywatności, został zakomentowany po tym, jak po wykonaniu kilku testów, okno to, przestało się pojawiać. Dla uściślenia - okno dotyczące Polityki prywatności pojawiało się w dwóch momentach - po wejściu na stronę oraz po zalogowaniu się. Gdy przestało pojawiać się po zalogowaniu, krok nr 2 został przeze mnie zakomentowany, gdyż Cypress zwracał niepowodzenie. W przypadku kroku nr 3, zakomentowanie jest wynikiem zmiany elementów badanych do testu. Wielkość okna strony, zmienia się podczas testowania, co powoduje, że badane do napisania kodu elementy, znikają podczas wykonywania testu, a w ich miejscu pojawiają się inne, co finalnie zwraca niepowodzenie testu. Na tym zakończyłam testy w przypadku Allegro i testowanie tej platformy, nie pojawi się w przyszłych postach.

Kod tego testu znajduje się pod tym adresem Kod testu logowania do Allegro

2. Przypadek testowy: Funkcjonalność logowania do sklepu internetowego Mohito

Krok 1: Jako istniejący użytkownik loguję się do aplikacji

Krok 2: Sprawdzam, czy użytkownik jest zalogowany i wylogowuję się

W przypadku sklepu Mohito, developerzy oznaczyli elementy logowania atrybutami data-selen, co może świadczyć o tym, że używają narzędzia Selenium do testów automatycznych. Jednak w późniejszych funkcjonalnościach, tych atrybutów nie widać, dlatego ten projekt, również nie będzie przeze mnie opisywany w późniejszych postach.

Kod tego testu znajduje się pod tym adresem Kod testu logowania do Mohito

3. Przypadek testowy: Funkcjonalność logowania do sklepu internetowego Reserved

Krok 1: Jako istniejący użytkownik loguję się do aplikacji

Krok 2: Sprawdzam, czy użytkownik jest zalogowany

Krok 3: Wylogowuję się

Ten test uważam za zdecydowanie najprzyjemniejszy w napisaniu. W przypadku logowania do sklepu Reserved, od razu dało się zauważyć, że kod przygotowany jest do testowania - elementy zostały oznaczone atrybutami data-selen, co podobnie jak w przypadku sklepu Mohito, może świadczyć o używaniu Selenium przez developerów. Dzięki tym atrubutom, wyszukiwanie elementów do napisania kodu moich kroków testowych, nie sprawiło mi żadnego problemu. Wszystkie kroki zostały wykonane przez Cypressa, z powodzeniem.

Kod tego testu znajduje się pod tym adresem Kod testu logowania do Reserved