#automatyzacjaTestCafe01-Pobranie, instalacja, konfiguracja, pierwszy projekt, pierwsze testy.

Dzień dobry, kolejny wpis, kolejny framework ze rodziny node.js!
Tym razem na tapetę wpada TestCafe.
Czym owy framework jest? Jest to lekki nastawiany, na praktycznie zerową konfiguracje ‘tool’ do testów end to end.
Sprawdzimy w praktyce jego instalacja i możliwości na prostych przykładach 🙂
Jako, że jest to framework nodowy, potrzebujemy node.js/npm.
A więc jeśli jeszcze nie macie noda na swoim systemie, standardowo odsyłam do odpowiedniego wpisu: https://gregkaqa.pl/index.php/2020/01/13/automatyzacjapuppeteer01-zapoznanie-sie-z-narzedziem-puppeteer-pobieranie-konfiguracja-prosty-test/
Również zachęcam do pobrania Visual Studio Code, to IDE tak czy siak wam się przyda do frameworków node.jsowych, również instrukcja w linku wyżej.

Weryfikacja poprawności node & instalacja framworka testcase

Testcafe czas na proste testy

Pobieramy przykładowy projekt testów prosto od producenta a więc link bezpośredni:
ttps://devexpress.github.io/testcafe/downloads/sample-test.zip
Zaś strona oficjalna projektu to: https://devexpress.github.io/testcafe.

Po pobraniu sample-test.zip wypakowujemy go gdzie chcemy ja na inny dysk E: oraz do innego folderu.
Zatem odpalamy cmd wpisujemy E: nastepnie cd projekty/testcafe i już jesteśmy w folderze z naszuymi testami o rozszerzeniu *.js

Po przejściu do właściwego folderu z testami, wydajemy polecenie: testcafe chrome test-example.js
gdzie właśnie fraza po testcafe to przeglądarka w jakiej nasze testy mają zostać uruchomione.

Ja TestCafe widzę pierwszy raz na oczy i naprawdę bardzo prosto było sobie ‘poradzić’, aby odpalić coś prostego.
Więc jak na początek dość intuicyjnie i prosto, więcej zajęło czekanie na pobranie i instalacje, niż samo odpalenie ‘sample testu’.

Sprawdźmy teraz drugą przeglądarkę jaką jest Firefox.
Wydajemy polecenie testcafe firefox test-example.js i patrzymy co się dzieje.

Jak widzimy poprawnie odpaliła się przeglądarka Firefox oraz w paosku adresu widzimy swój lokalny adres, oznacza to po prostu działanie tej usługi jako serwer lokalny. Dodatkowo widnieje tam też ikona robota czyli informacja dotycząca sterowania przeglądarki z poziomu drivera.

Analiza example test i dostosowanie pod siebie do innego testu

Uruchomiliśmy już ‘cudzy’ skrypt czas porobić coś własnego, bo o to w tym wszystkim chodzi.
W archiwum .zip, na którym ciągle bazujemy znajdują się dwa pliki, otwórzmy je aby widzieć je oba.

Przygotowany przykład składa się z dwóch plików, jeden plik to testy(który jak widać już staram się przerobić pod coś innego), zaś drugi plik to model strony, w którym nie ma akcji a są przechwytywane obiekty strony.
Czyli klasy, które jak widać w linijce numer 1 pliku z testami są zaimportowane w 6 linijce tworzymy nowy obiekt właśnie typu Page i możemy mieć dostęp do pól z konstruktora np. macOSRadioButton.
Na przykładzie tego guzika jest on po prostu obiektem w klasie Page pliku basi-page-model.js.
Od razu jest na nim wykonane przypisanie akcji Selektora na podstawie tutaj akurat input i jego wartości.this.macOSRadioButton = Selector(‘input[type=radio][value=MacOS]’);
Nie ma się co za bardzo rozpisywać czas przerobić lekko ten przykładowy plik.

Przesiądziemy się na Visual Studio Code, w tym celu instalujemy dwa rozszerzenia do TestCafe, jedno z nich to runner, który być może ułatwi nam uruchamianie testów.

Otwieramy wcześniejszy projekt file->open folder.

Visual Code Studio niestety nie wie, gdzie jest nasza paczka z TestCafe, zatem musimy ją wskzać sami.

Dla odmiany odpalam test w Edge, jak widać, tutaj lekka konfiguracja ale nie musimy się posługiwać wierszem polecań w celu uruchomienia naszych testów, wszystko wykonujemy paroma krokami.
Otwieramy folder, dostosowujemy rozszerzenie czyli wskazanie nmp(dostęp VSCode do modułów, ponieważ on nie wie gdzie są), odpalenie testów na pożądanej przeglądarce.

Dodanie prostych asercji oraz podsumowanie całości

Włączmy sobie jeszcze tryb headless, czyli tryb gdzie driver przeglądarki działa w tle przez co sama przeglądarka ‘działa w tle’, fizycznie się nie wyświetlając.

Robimy to też w ustawieniach, które są swoistym ‘poradnikiem’.
Gdyż po kliknięciu edit in settings.json, od razu generuj nam pusty lub pomyślny atrybut, my mamy tylko zmienić/dopisać wartość, co jest naprawdę wygodnym rozwiązaniem.

Zakomentowaliśmy pierwszy test, w drugim teście sprawdzamy czy element body czyli sekcja z linkami wyników, zawiera słowo text. Owego słowa nie ma, stąd dostajemy dokładnie objaśnienie co, jak gdzie przeszukał.
Zastosowałem tutaj .innerText aby szukał po atrybutach tekstowych.
Eql to skrót od equals czyli równa się czyli 1do1

Zastujemy słowo contains, poniżej zamieszam po jednym przypadku pozytywnym i jeden negatywny.

Na koniec jeszcze same linki.
Dla mojego wymyślonego przypadku najrozsądniej było brać kontener o identyfikatorze links, poprzedzamy go hashem.

Podsumowanie

To by było na tyle z TestCafe, mam nadzieje, że wpis okazał się pomocny.
Postanowiłem uruchomić ostatnio GitHuba. Wrzuciłem tam ten projekt i zapewne będą się pojawić kolejne.
Być może wsteczne wraz z odpowiednimi odnośnikami.
Link do projektu z tego wpisu: https://github.com/gregkaqa/testcafebasictests
Krótko reasumując TestCafe, wspaniały framework. Konfiguracja łopatologiczna, łatwa.
Bogata dokumentacja https://devexpress.github.io/testcafe/documentation/getting-started/.
Poziom wejścia we framework naprawdę, nie ma dużych wymagań.
Nawet nie rozumiejąc JavaScripta, można na podstawie sampli i intuicji coś ‘pokodować’.
W międzyczasie doszkalając się z JSa. Sam framework dość popularny obok chociażby Cypressa.
No cóż mogę dodać? Gorąco polecam spróbować swoich sił TestCafe.
Być może pojawi się kolejna część, gdzie poruszę bardziej zaawansowane tematy.
A tymczasem trzymajcie się znośnego tygodnia 🙂