Cypress uruchamianie testów na Gitlabie

Cypress IO

 804 

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/**/*"
 
  1. Pierwszy element to obraz dockerowy który pobieramy do naszego projektu. 
  2. test_name – ten element będzie wyświetlany na gitlabie – gdzie będzie wykonywana seria testów (np. z danej klasy testowej):

Cypress uruchamianie testów na Gitlabie - some tests

     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:

Cypress uruchamianie testów na Gitlabie - stages

 

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.

.job_template: &job_configuration  
  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
 
Później można to wykorzystywać w dalszych cyklach, co jak widzimy skraca nasz skrypt testowy diametralnie. 

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:

Cypress uruchamianie testów na Gitlabie - 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.