Testy na różnych środowiskach

Language

date

Aug 25, 2023

slug

playwright-testy-na-roznych-srodowiskach

author

status

Public

Konfiguracja Projektów

Możemy wykorzystać konfigurację projektów (🔗https://playwright.dev/docs/test-projects)

W pliku playwright.config.ts dodajemy konfigurację projektów:


projects: [
    {
      name: 'local',
      use: {
        ...devices['Desktop Chrome'],
        baseURL: 'https://localhost:3000'
      },
    },
    {
      name: 'dev',
      use: {
        ...devices['Desktop Chrome'],
        baseURL: 'http://staging.example.test/'
      },
    },
],

Następnie daną konfigurację możemy uruchomić z linii komend:

npx playwright test --project=local

albo:

npx playwright test --project=dev

Powyższe komendy spowodują uruchomienie odpowiedniego projektu z konfiguracji.

Każdy z tych projektów może mieć swoje własne ustawienia dostosowane do środowiska, na którym uruchamiamy testy😉

⚠️ Jeśli nie podamy parametru --project=, to Playwright uruchomi od razu wszystkie projekty!

✅ Zalety:

Możemy wykonać równolegle testy na wielu środowiskach na raz

Nie wymaga dodatkowych bibliotek i bazuje na domyślnym mechanizmie PW

Możemy wybierać z wtyczki playwright/UI mode, gdzie chcemy uruchomić nasze testy

❌ Wady:

Nasze projekty robią się obszerne, bardziej skomplikowanej i trudniejsze w utrzymaniu.

Gdy mamy kilka projektów np: dla różnych przeglądarek, to musimy wtedy wszystkie zduplikować z parametrem dotyczącym środowiska.

Biblioteka dotenv

Sposób ten bazuje na bibliotece dotenv (🔗https://www.npmjs.com/package/dotenv), którą również zalecają twórcy Playwright (🔗https://playwright.dev/docs/test-parameterize#env-files)

✅ Zalety:

Daje więcej możliwości konfiguracji i parametryzacji

Poza parametrami z adresami, można też skonfigurować inne dane, jak hasła, dane testowe etc.

❌ Wady:

Wymaga wykorzystania zewnętrznej biblioteki

Sami musimy zaimplementować rozwiązanie w naszym kodzie

💡

W kursie 🔗TESTY AUTOMATYCZNE Z PLAYWRIGHT pokazujemy dodatkowo jak wydzielić dotenv do konfiguracji globalSetup. Dzięki temu nie trzymamy zbyt wielu ustawień w konfiguracji😉

Sposób 1 (z dokumentacji Playwright)

Modyfikujemy plik playwright.config.ts i dodajemy wykorzystanie dotenv:


import { defineConfig } from '@playwright/test';
import dotenv from 'dotenv';
import path from 'path';

dotenv.config();

export default defineConfig({
  use: {
    baseURL: process.env.STAGING === '1' ? 'http://staging.example.test/' : 'https://localhost:3000',
  }
});

Następnie tworzymy plik .env:

STAGING=0

I uruchamiamy testy z odpowiednim przełącznikiem (np. w PowerShell):

$env:STAGING="1"; npx playwright test

💡

Na innych systemach / konsolach ustawianie zmiennych wygląda odrobinę inaczej.

W CMD na Windows:

set STAGING=1

W Bash na Linuxie:

export STAGING=1

Sprawdzimy zmienną wykonując polecenie: echo $STAGING

Wartość STAGING zostanie użyta w konfiguracji i na jej podstawie zostanie wybrany odpowiedni adres.

✅ Zalety:

Korzystamy ze wskazań dokumentacji

Szybkie rozwiązanie

❌ Wady:

Ograniczenie do dwóch środowisk

Mało czytelny sposób konfigurowania (przełącznik w zmiennej środowiskowej)

Brak wsparcia dla rozszerzenia o dodatkowe zmienne poza baseURL

To rozwiązanie jest mocno ograniczone, dlatego proponujemy kolejne sposoby 😉

Sposób 2 (rozszerzony)

W pliku playwright.config.ts zmieniamy ustawienia sekcji use - aby baseURL był brany ze zmiennej środowiskowej process.env.BASE_URL:


import { defineConfig } from '@playwright/test';
import dotenv from 'dotenv';
import path from 'path';

dotenv.config();
dotenv.config({ path: path.resolve(__dirname, `.env.${process.env.ENV}`) });

export default defineConfig({
  use: {
    baseURL: process.env.BASE_URL,
  }
});

Następnie tworzymy pliki z ustawieniami dla różnych środowisk.

Zawartość pliku .env.staging:

BASE_URL=http://staging.example.test/

Zawartość pliku .env.test:

BASE_URL=http://localhost:3000

Teraz uruchamiamy testy z odpowiednim przełącznikiem (w PowerShell):

$env:ENV="test"; npx playwright test

albo:

$env:ENV="staging"; npx playwright test

Po wykonaniu powyższych komend, odpowiedni plik .env zostanie odczytany a konfiguracja w nim zawarta - zostanie użyta w testach 😉

Możemy dodać jeszcze takie ustawienie dla baseURL w configu: baseURL: process.env.BASE_URL ?? 'http://localhost:3000',

Przy braku zmiennej środowiskowej testy automatycznie uruchomią się na adresie 'http://localhost:3000'

✅ Zalety:

Możemy podpiąć dowolną liczbę środowisk

Możemy mieć dowolną ilość zmiennych w tych środowiskach (nie tylko adres baseURL)

❌ Wady:

Brak wsparcia uruchamiania testów bez ustawiania zmiennych (tylko baseURL ustawiony na sztywno w sekcji use)

Brak wsparcia konfiguracji gdy używamy wtyczki VSC Playwright

Brak możliwości ustawienia danego pliku ze zmiennymi jako domyślnego w naszej konfiguracji

Domyślny adres URL zaszyty wewnątrz konfiguracji

Sposób 3 (ze wsparciem wtyczki i podstawowych poleceń)

W trosce o elastyczność dodajmy możliwość wyboru środowiska zarówno z wiersza poleceń jak i konfiguracji Playwright.

W naszej konfiguracji Playwright chcielibyśmy wskazać dane środowisko na jakim chcemy pracować.

W poprzednim przykładzie musieliśmy ustawiać zmienną środowiskowej ENV przed każdym poleceniem uruchomienia testów: $env:ENV="test"; npx playwright test.

Teraz chcemy uruchomić testy z danym środowiskiem przez polecenie npx playwright test lub po prostu z rozszerzenia VSC Playwright Test.

Uzyskamy to ustawiając na sztywno środowisko poprzez obiekt defaultEnvironment jak w przykładzie:


import { defineConfig, devices } from '@playwright/test';
import dotenv from 'dotenv';
import path from 'path';

enum environments {
  test = 'test',
  staging = 'staging',
  prod = 'prod',
}

const defaultEnvironment = environments.staging;
const environment = process.env.ENV ?? defaultEnvironment;
dotenv.config({ path: path.resolve(__dirname, `.env.${environment}`) }

Omówmy elementy kodu:


enum environments {
  test = 'test',
  staging = 'staging',
  prod = 'prod',
}

W zmiennej environments przechowujemy nazwy środowisk.


const defaultEnvironment = environments.staging;

W powyższej linii ustawiamy manualnie dane środowisko.


const environment = process.env.ENV ?? defaultEnvironment;

Na koniec sprawdzamy czy nie ma ustawionej zmiennej środowiskowej ENV. Jeśli zmienna ENV nie zostanie ustawiona wtedy wykorzystamy naszą zmienną defaultEnvironment w ustawieniach.

Użycie i polecenia

Gdy ustawimy środowisko w pliku playwright.config.ts uruchomimy testy z naszym ustawieniem poprzez:

npx playwright test

lub przez wtyczkę:

Oczywiście dalej możemy przed poleceniem dodać ustawienie zmiennej środowiskowej (przydatne dla środowisk CI/CD):

$env:ENV="test"; npx playwright test

Wtedy też ustawienie w konfiguracji defaultEnvironment zostanie zignorowane.

✅ Zalety:

Możemy ustawić środowisko w konfiguracji Playwright

Brak potrzeby ustawiania środowiska w wierszu poleceń

Możemy uruchamiać w ten sposób testy bezpośrednio z VSC na danym środowisku

Uruchamianie z użyciem zmiennej środowiskowej jest też wspierane (np przy Ciągłej Integracji)

Pełna dowolność przy ustawianiu zmiennych w plikach .env

❌ Wady:

Większe skomplikowanie kodu poprzez ustawianie środowiska w za pomocą dwóch sposobów

Potrzeba przygotowania dokumentacji do opisu sposobów uruchamiania testów

Polecenia z ustawieniem środowiska w skryptach `package.json`

Nie zalecamy ustawiać środowiska w package.json ze względu na zarządzanie konsolami i problemy w ustawianiu zmiennych środowiskowych w skryptach.

Nasze skrypty w package.json powinny być niezależne od środowiska na jakim działamy.

Podsumowanie

W tym artykule przedstawiłem kilka przykładowych sposobów na konfigurację naszych testów😉 Które podejście wybrać? Wszystko zależy od Twoich potrzeb i tego, co lepiej się sprawdzi w Twoim projekcie.

Testy na różnych środowiskach

Konfiguracja Projektów

Biblioteka dotenv

Sposób 1 (z dokumentacji Playwright)

Sposób 2 (rozszerzony)

Sposób 3 (ze wsparciem wtyczki i podstawowych poleceń)

Użycie i polecenia

Polecenia z ustawieniem środowiska w skryptach package.json

Podsumowanie

Polecenia z ustawieniem środowiska w skryptach `package.json`