E2E testēšanas automatizācija ar Playwright — praktisks ceļvedis

Pēc 20+ produkcijas E2E testu komplektu rakstīšanas valdības sistēmām, fintech platformām un SaaS produktiem - lūk, kas patiešām strādā ar Playwright un kas tērē Jūsu laiku.

Kāpēc Playwright, nevis Cypress/Selenium

• Daudzu pārlūku atbalsts - Chromium, Firefox, WebKit vienā testu izpildē. Cypress natīvi atbalsta tikai Chromium.
• Automātiskā gaidīšana - Vairs nav jāraksta sleep(2000). Playwright automātiski gaida elementus.
• Tīkla pārtvere - API mokošana, resursu bloķēšana, atbilžu modificēšana. Iebūvēts, bez papildus spraudņiem.
• Paralelisms pēc noklusējuma - Workers izpilda testus paralēli. 100 testi 2 minūtēs, nevis 20.
• Codegen - npx playwright codegen ieraksta Jūsu klikšķus un ģenerē testa kodu.

Iestatīšana 60 sekundēs

npm init playwright@latest
# Izveido: playwright.config.ts, tests/, .github/workflows/

# Palaist testus
npx playwright test

# Palaist ar UI režīmu (labākais atkļūdošanai)
npx playwright test --ui

# Palaist konkrētu testu
npx playwright test login.spec.ts

# Ģenerēt testu no pārlūka ieraksta
npx playwright codegen https://your-app.com

Page Object modelis

Vissvarīgākais modelis uzturāmiem testiem. Bez tā viena selektora maiņa salauž 50 testus. Ar to - maināt vienu failu.

// pages/login.page.ts
import { Page } from '@playwright/test';

export class LoginPage {
  constructor(private page: Page) {}

  async goto() {
    await this.page.goto('/login');
  }

  async login(email: string, password: string) {
    await this.page.fill('[data-testid="email"]', email);
    await this.page.fill('[data-testid="password"]', password);
    await this.page.click('[data-testid="submit"]');
  }

  async expectError(message: string) {
    await expect(this.page.locator('.error')).toContainText(message);
  }
}

// tests/login.spec.ts
import { test, expect } from '@playwright/test';
import { LoginPage } from '../pages/login.page';

test('successful login', async ({ page }) => {
  const login = new LoginPage(page);
  await login.goto();
  await login.login('user@test.com', 'password123');
  await expect(page).toHaveURL('/dashboard');
});

5 piemēri, kas ietaupa stundas

1. Izmantojiet data-testid, nevis CSS selektorus

// Slikti - salūst, kad mainās dizains
await page.click('.btn-primary.mt-4');

// Labi - stabīls neatkarīgi no stiliem
await page.click('[data-testid="submit-form"]');

2. API-first autentifikācija

Neautentificējieties caur UI katram testam. Izmantojiet API izsaukumus, lai iegūtu autentifikācijas tokenus, un tad injicējiet tos.

// fixtures/auth.ts
test.beforeEach(async ({ page, request }) => {
  const res = await request.post('/api/auth/login', {
    data: { email: 'test@test.com', password: 'pass' }
  });
  const { token } = await res.json();
  await page.addCookies([{
    name: 'auth_token', value: token,
    domain: 'localhost', path: '/'
  }]);
});

3. Tīkla mokošana nestabilam API

await page.route('**/api/payments', route => {
  route.fulfill({
    status: 200,
    body: JSON.stringify({ success: true, id: 'mock_123' })
  });
});

4. Vizuālā regresija ar ekrānuzņēmumiem

// Pirmā izpilde izveido bāzes līniju, nākamās salīdzina
await expect(page).toHaveScreenshot('dashboard.png', {
  maxDiffPixels: 100
});

5. Atkārtojiet nestabilas pārbaudes, nevis nestabilus testus

// Slikti - atkārto visu testu
test('...', { retries: 3 }, async () => { ... });

// Labi - atkārto tikai apgalvojumu ar automātisku gaidīšanu
await expect(page.locator('.toast'))
  .toBeVisible({ timeout: 5000 });

CI/CD integrācija (GitHub Actions)

name: E2E Tests
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npx playwright test
      - uses: actions/upload-artifact@v4
        if: failure()
        with:
          name: playwright-report
          path: playwright-report/

Mūsu testēšanas kontrolsaraksts

1. Vispirms smoke testi - vai lietotājs var pieslēgties, redzēt paneli, veikt galveno darbību?
2. Otro happy paths - pilni lietotāju ceļojumi (reģistrācija → funkcijas izmantošana → rezultāta pārbaude)
3. Trešo kļūdu ceļi - nederīga ievade, tīkla kļūdas, atteikta pieeja
4. Beigās malāsgadījumi - tukši stāvokļi, ļoti garš teksts, vienlaicīgi lietotāji, pārlūkam specifiski bagi

Šī secība ir svarīga. Ja smoke testi neiztur, nekas cits nav svarīgs. Ja happy paths strādā, Jums ir piegādājams produkts. Kļūdu apstrāde un malāsgadījumi ir pulēšana.

Mēs samazinājām mūsu klienta manuālās testēšanas laiku par 70% ar šo pieeju. Testu komplekts izpildās 4 minūtēs CI vidē un notver 95% regresiju pirms cilvēku QA pieskaras buildam.