Playwright uruchamianie testów na Gitlabie

Playwright uruchamianie testów na Gitlabie – to wpis pokazujący w jaki sposób w kilku krótkich krokach dokonać integracji i uruchamiać testy Playwrighta na Gitlabie. Jeżeli jesteś zainteresowany innymi wpisami dotyczącymi Playwrighta , zapraszamy do odpowiedniego działu.

Wprowadzenie

Tworząc testy automatyczne z wykorzystaniem Playwrighta , 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 Playwrighta – dostępne na DockerHub. 

I. Najprostsza wersja

W naszym projekcie testowym tworzymy plik gitlab-ci.yml a następnie uzupełniamy go w najprostszy sposób:

image: mcr.microsoft.com/playwright:v1.25.0-focal

test_name:
  tags:
    - runner-name
before_script:
    - npm ci
script:
   - npm run test:spec --headed

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):

     3. tags: runner-name – to miejsce gdzie wskazujemy runnera na którym będą uruchomione testy
     4. Script – instalacja Playwrighta 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
before_script:
  - npm ci
script:
  - npm run test:spec --headed (określamy ścieżkę)

test_name:
tags:
  - runner-name
stage: after
before_script:
  - npm ci
script:
  - npm run test:spec --headed (określamy ścieżkę)

Efektem tej pracy będzie uruchomienie testów w takiej postaci:

III. Raporty i artefakty

Jeżeli potrzebujecie zapisywać raporty i pobierać je z Gitlaba – wystarczy w ramach pliku gitlab-ci.yml dodać:

artifacts:
    when: always
    paths:
      - ./playwright-report/**
expire_in: 10 days

IV. 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.

V. 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: mcr.microsoft.com/playwright:v1.25.0-focal

tags:
  - nazwa-runnera
    artifacts:
       when: always
    paths:
       - ./playwright-report/**
expire_in: 10 days
retry:
    max: 2
    when:
    - always

.some-script: &some-script
    - npm ci

stages:
  - test

e2e:
  <<: *job_configuration  
  stage: test
  before_script:
    - *some-script
  script:
    - npm run test:spec --headed

  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

Playwright 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ł Playwright na rozwój, będziemy poszerzać wpisy na ten temat. Wszelkie artykuły związane z Playwrightem znajdziecie w dedykowanym dziale.

0