studenti.rs home page
Vesti i updatei Studija slučaja

Playwright E2E testiranje za WordPress: kako smo napisali 164 testa za platformu bez ijednog

· 6 min
Deo 5 od 5 · Preobrazaj platforme
← Prethodni
Sadržaj

Stari sajt je imao nula automatizovanih testova.

Nula.

Za platformu sa 250.000 korisnika.

Dolazim iz Vercel/Shopify ekosistema gde je CI/CD standard. Gde deploy bez testova nije deploy. Gde "radi na mom računaru" nije odgovor.

WordPress svet je… drugačiji.

Zašto E2E, ne unit

Unit testovi za WordPress su mogući. PHPUnit, mocking, isolation.

Ali šta bi oni zapravo testirali?

Da hook radi? Da funkcija vraća tačnu vrednost?

Ono što me zapravo zanima: Da li korisnik može da se registruje, uploaduje dokument, dobije PRO, i preuzme?

To je E2E. Ceo flow. Prava baza. Prava sesija.

Playwright: Jedini izbor

Playwright podržava:

  • Chromium (desktop)
  • WebKit (iPhone 14 simulacija)
  • Firefox (ako treba)
  • Parallel execution
  • Per-test isolation
  • Tracing i screenshots

Cypress je alternativa. Ali Playwright bolje radi sa više browser-a i ima native async/await.

Arhitektura: Per-worker auth

Problem: Parallel testovi dele state. Ako test A i test B koriste istog korisnika, međusobno se ruše.

Rešenje: Svaki worker ima svog test korisnika.

Global Setup (runs once)
  1. Creates N test users via WP-CLI (e2e-worker-0, 1, 2, ...)
  2. Authenticates each user and saves storage state
  3. Saves auth to playwright/.auth/worker-N.json

Parallel Test Execution
  Worker 0 → worker-0.json → [email protected]
  Worker 1 → worker-1.json → [email protected]
  Worker 2 → worker-2.json → [email protected]
  Worker 3 → worker-3.json → [email protected]

4 workera = 4 nezavisna korisnika = potpuni paralelizam bez konflikata.

Custom E2E API

WordPress nema native način da test manipuliše state.

Rešenje: 7 REST endpoint-a samo za testiranje:

Endpoint Svrha
DELETE /user Obriši test korisnika (e2e- prefix obavezan)
GET /user-by-email Dobij user ID i metadata
POST /user-state Postavi verification level, PRO status, credits
POST /approve-post Force approve post, bypass review, grant rewards
GET /user-status Dobij PRO status, downloads left, verified level
GET /post-status Dobij post metadata, taxonomies, processing status
GET /user-posts Dobij korisnikove postove sa statusom

Ovi endpoint-i postoje SAMO u local/test okruženju. STUDENTI_E2E_TOKEN header za auth.

Golden path test

Najvažniji test: Ceo user journey.

test('Golden path: registration → upload → PRO → download', async () => {
  // 1. Register
  await page.goto('/registracija/');
  await page.fill('[name="email"]', email);
  await page.fill('[name="password"]', password);
  await page.click('button[type="submit"]');

  // 2. Verify email (via E2E API)
  await e2eApi.setUserState(userId, { verified: 'email' });

  // 3. Upload document
  await page.goto('/posalji-dokument/');
  await page.setInputFiles('input[type="file"]', testPdf);
  await page.click('button[type="submit"]');

  // 4. Approve via E2E API (bypass async processing)
  await e2eApi.approvePost(postId);

  // 5. Verify PRO status
  const status = await e2eApi.getUserStatus(userId);
  expect(status.is_pro).toBe(true);

  // 6. Download document
  await page.goto(`/download?document=${otherPostId}`);
  await page.click('button:has-text("Potvrdi")');

  // 7. Verify in library
  const library = await e2eApi.getUserLibrary(userId);
  expect(library).toContainEqual(otherPostId);
});

Ako ovaj test prolazi, platforma radi.

Test coverage po funkciji

Suite Šta testira
golden-path.spec.ts Kompletan user journey
home.spec.ts Homepage, hero, FAQ, recent docs
search.spec.ts Search functionality
auth.spec.ts Login, registration
seo.spec.ts Meta tags, structured data, robots
bookmarks.spec.ts Bookmark save/remove
download.spec.ts Download flow, credits
upload.spec.ts Document upload
user-flagging.spec.ts Admin flagging
membership.spec.ts PRO features

Mobile testing: WebKit

Desktop test prolazi. Ali šta ako mobile layout ima bug?

// playwright.config.ts
projects: [
  { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
  { name: 'webkit', use: { ...devices['iPhone 14'] } },
]

Isti testovi, dva viewport-a. Mobile sticky header, modali, touch interactions — sve testirano.

Lighthouse integration

Performance nije opciona:

Performance: 73
Accessibility: 87
Best Practices: 100
SEO: 100

Lighthouse trči kao standalone skripta (Playwright integracija je flaky).

Thresholds preko environment variables:

LIGHTHOUSE_PERFORMANCE_THRESHOLD=50
LIGHTHOUSE_ACCESSIBILITY_THRESHOLD=80

Staging smoke tests

Pre svakog production deploya: 25 smoke testova na staging-u.

  • Homepage loads
  • Search works
  • Login works
  • Upload form displays
  • Document pages load

9 testova preskočeno (require local-only features).

Najtežji deo

Najtežji deo nije bio pisanje testova.

Bio je testiranje WordPress-a.

PHP sesije. Cookie-based auth. AJAX forms. CSRF tokens. Async processing.

Svaki od ovih je zahtevao custom rešenje:

  • Storage state za sesije
  • E2E API za state manipulation
  • Polling za async operations
  • Nonce handling za AJAX

WordPress nije napravljen za E2E testiranje. Ali sa dovoljno custom infrastrukture, funkcioniše.

Nula testova nije opcija za platformu sa 250.000 korisnika.

Da, WordPress testiranje je teško. Da, treba custom infrastruktura. Da, treba vremena za setup.

Ali alternativa — deploy pa se nadaj — nije profesionalna.

164 testova ne garantuje da nema bugova. Ali garantuje da 164 stvari koje sam eksplicitno definisao rade.