Cypress uruchamianie testów na Gitlabie – to wpis pokazujący w jaki sposób w kilku krótkich krokach dokonać integracji i uruchamiać testy Cypressa na Gitlabie. Jeżeli jesteś zainteresowany innymi wpisami dotyczącymi Cypressa, zapraszamy do odpowiedniego działu.
Wprowadzenie
Tworząc testy automatyczne z wykorzystaniem Cypressa, bardzo ważnym aspektem jest aby wykorzystywać nasze testy w codziennej pracy. Jaki sens jest jednak tworzyć testy automatyczne a później uruchamiać je tylko w środowisku lokalnym? Oczywiście stworzone testy pomogą szybciej sprawdzić czy nie mamy do czynienia z regresją, natomiast winniśmy zmierzać w kierunku tworzenia testów i uruchamiania ich w naszym środowisku w sposób automatyczny.
Tworzenie gitlab-ci.yml
Chcąc uruchamiać testy z poziomu gitlaba nasze testy będą opierać się o stworzenie pliku gitlab-ci.yml, który będzie naszym centrum dowodzenia i zarządzania. Do uruchomienia naszych testów konieczne będzie:
- runner na gitlabie, na podstawie którego testy będą uruchamiane (pytaj Devopsów o tag)
- obraz dockerowy cypressa – dostępne na Githubie.
I. Najprostsza wersja
W naszym projekcie testowym tworzymy plik gitlab-ci.yml a następnie uzupełniamy go w najprostszy sposób:
image: cypress/base:14.17.6-slim
test_name:
tags:
- runner-name
script:
- npm install
- npx cypress verify
- npx cypress run --spec "cypress/integration/Desktop/Test/**/*"
- Pierwszy element to obraz dockerowy który pobieramy do naszego projektu.
- test_name – ten element będzie wyświetlany na gitlabie – gdzie będzie wykonywana seria testów (np. z danej klasy testowej):
3. tags: runner-name – to miejsce gdzie wskazujemy runnera na którym będą uruchomione testy
4. Script – instalacja cypressa i egzekucja testów
II. Tworzenie stage
W ramach naszych testów może zachodzić konieczność tworzenia faz egzekucji testów.
stages:
- test
- after
Następnie w ramach testów musimy dodawać określenie w ramach którego stage uruchamiamy daną grupę testów:
test_name:
tags:
- runner-name
stage: test
script:
- npm install
- npx cypress verify
- npx cypress run --spec "cypress/integration/Desktop/Test/**/*"
test_name:
tags:
- runner-name
stage: after
script:
- npm install
- npx cypress verify
- npx cypress run --spec "cypress/integration/Desktop/Test/**/*"
Efektem tej pracy będzie uruchomienie testów w takiej postaci:
III. Wybór przeglądarki
W ramach tworzenia gitlab-ci możemy wybierać przeglądarkę na której będą przeprowadzane testy – np. jak na powyższym screenie. Ważne tutaj jest aby wybierać odpowiednie obrazy dockerowe które są dostępne na wskazanej wcześniej stronie. Ważne abyście zwrócili uwagę na wersję Node w ramach obrazu dockerowego.
- cypress/browsers:node16.14.0-chrome99-ff97 – w ramach tego obrazu możemy uruchamiać testy na Chrome i Firefox
- cypress/browsers:node16.14.0-edge – w ramach tego obrazu możemy uruchamiać testy na MS Edge
- npx cypress run --spec "cypress/integration/Desktop/Test/**/*" --browser chrome
Dzięki temu odpalimy testy na przeglądarce Chrome. Wykorzystanie Firefox czy Edge będzie analogiczne.
IV. Raporty i artefakty
Jeżeli masz zainstalowany mochawesome-reporter – możesz dodawać tworzenie raportów. Standardowo musicie dodać informację w cypress.json, zaś w ramach gitlab-ci
artifacts:
when: always
paths:
- ./cypress/videos/**
- ./cypress/screenshots/**
- ./cypress/report/**
expire_in: 10 days
V. Powtarzanie testu (retry)
Zdarzyć się może że przydatne dla Was może myć ponowne uruchomienie testów. Możemy ponownie uruchamiać testy gdy będzie fail. Poniżej ponowne uruchomienie klasy testowej będzie zawsze:
retry:
max: 2
when:
- always
Możliwe jest też wdrożenie szczególnych przypadków dla ponownego uruchomienia testów:
-
always: Retry on any failure (default).
-
unknown_failure: Retry when the failure reason is unknown.
-
script_failure: Retry when the script failed.
-
api_failure: Retry on API failure.
-
stuck_or_timeout_failure: Retry when the job got stuck or timed out.
-
runner_system_failure: Retry if there is a runner system failure (for example, job setup failed).
-
runner_unsupported: Retry if the runner is unsupported.
-
stale_schedule: Retry if a delayed job could not be executed.
-
job_execution_timeout: Retry if the script exceeded the maximum execution time set for the job.
-
archived_failure: Retry if the job is archived and can’t be run.
-
unmet_prerequisites: Retry if the job failed to complete prerequisite tasks.
-
scheduler_failure: Retry if the scheduler failed to assign the job to a runner.
-
data_integrity_failure: Retry if there is a structural integrity problem detected.
VI. Refactoryzacja
Przy rozbudowanych plikach gitlab-ci.yml może zachodzić konieczność tworzenie dużych i skomplikowanych poleceń. Warto wówczas uwspólnianie rzeczy przesuwać by były re-używalne.
image: cypress/browsers:node16.14.2-slim-chrome100-ff99-edge
tags:
- runner-name
artifacts:
when: always
paths:
- ./cypress/videos/**
- ./cypress/screenshots/**
- ./cypress/report/**
expire_in: 10 days
retry:
max: 2
when:
- always
.some-script: &some-script
- npm install
- npm i --save-dev cypress-mochawesome-reporter
- npx cypress verify
chrome_desktop:
allow_failure: true
<<: *job_configuration
stage: test
script:
- *some-script
- npx cypress run --spec "cypress/integration/Desktop/**/*" --browser chrome
VII. Opóźnienie w uruchomieniu
Możemy mieć czasami potrzebę by jakaś klasa testowa czy grupa uruchamiała się z opóźnieniem. Z tym przychodzi nam rozwiązanie w postaci:
when: delayed
start_in: 4 minutes
Schedules
Jeżeli chcemy tak przygotowane testy w ramach naszego repozytorium, możemy uruchamiać cyklicznie. Z pomocą przychodzi nam Gitlab i zakładka CI/CD – Schedules:
Tutaj pełna dowolność, ważne jest abyście uruchamiali testy wtedy – kiedy jest wam potrzebne.
Podsumowanie
Cypress uruchamianie testów na Gitlabie – to kolejny wpis mający zachęcić Was do instalacji i sprawdzenia narzędzia. Z racji popularyzacji narzędzia i dużego wsparcia które otrzymał Cypress na rozwój, będziemy poszerzać wpisy na ten temat. Wszelkie artykuły związane z Cypress IO znajdziecie w dedykowanym dziale.
