End-to-End Testing
Also Known As
E2E testing
Playwright
Cypress
browser testing
TL;DR
Testing complete user flows through a real browser against a running application — verifying that all layers work together from UI to database.
Explanation
E2E tests (Playwright, Cypress) drive a real browser: click buttons, fill forms, assert page content. They test the full stack — frontend, API, backend, database — in a realistic environment. The trade-off: slow (seconds per test), flaky (timing issues, external dependencies), and expensive to maintain. The test pyramid says E2E should be sparse — cover critical user journeys (checkout, signup, core workflow) and leave edge cases to unit and integration tests.
Diagram
flowchart LR
PLAYWRIGHT[Playwright or Cypress] --> BROWSER2[Real browser<br/>Chromium Firefox]
BROWSER2 --> CLICK[Click buttons fill forms<br/>assert page content]
CLICK --> STACK[Tests full stack<br/>UI API DB]
subgraph Best_Practices
WAIT[Wait for elements<br/>not arbitrary timeouts]
SELECTORS[Use data-testid selectors<br/>resilient to style changes]
SPARSE[Few E2E tests<br/>critical paths only]
PARALLEL[Run in parallel<br/>across browsers]
end
subgraph Failures
SCREENSHOT[Capture screenshot on fail]
VIDEO[Record video on fail]
end
style STACK fill:#6e40c9,color:#fff
style WAIT fill:#238636,color:#fff
style SCREENSHOT fill:#1f6feb,color:#fff
Common Misconception
✗ More E2E tests means better coverage — E2E tests are slow and fragile; a test pyramid with many unit tests, some integration tests, and few E2E tests is more reliable and faster.
Why It Matters
E2E tests catch integration failures that unit tests cannot — a correctly-implemented API that is called with the wrong parameters by the frontend is only caught at the E2E layer.
Common Mistakes
- Too many E2E tests — slow CI, high maintenance burden, flaky failures breed distrust of the whole suite.
- No wait strategies — hard-coded sleeps instead of waiting for elements; flaky tests.
- Running E2E against production — tests create real data, send real emails, charge real cards.
- Not capturing screenshots/videos on failure — debugging E2E failures without visual context is very slow.
Code Examples
✗ Vulnerable
// Flaky E2E — hardcoded sleep instead of waiting:
await page.click('#submit-btn');
await page.waitForTimeout(3000); // Hope 3s is enough
await expect(page.locator('#success-msg')).toBeVisible();
// Fails on slow CI, passes locally — nightmare to debug
✓ Fixed
// Playwright — wait for element, not arbitrary time:
await page.click('#submit-btn');
await expect(page.locator('#success-msg')).toBeVisible({ timeout: 10_000 });
// Waits up to 10s, passes as soon as element appears
// Structure: test critical paths only
test('user can complete checkout', async ({ page }) => {
await page.goto('/products');
await page.click('[data-testid="add-to-cart"]');
await page.click('[data-testid="checkout"]');
await page.fill('#card-number', '4242424242424242');
await page.click('#pay-now');
await expect(page.locator('.order-confirmation')).toBeVisible();
});
References
Tags
🤝 Adopt this term
£79/year · your link shown here
Added
15 Mar 2026
Edited
22 Mar 2026
Views
27
🤖 AI Guestbook educational data only
|
|
Last 30 days
Agents 0
No pings yet today
No pings yesterday
Amazonbot 7
Perplexity 6
Google 4
Ahrefs 2
Unknown AI 2
ChatGPT 1
Majestic 1
Also referenced
How they use it
crawler 22
crawler_json 1
Related categories
⚡
DEV INTEL
Tools & Severity
🟡 Medium
⚙ Fix effort: High
⚡ Quick Fix
Use Playwright or Cypress for E2E tests on your 5 most critical user journeys only — E2E tests are slow and brittle; keep them minimal and fix the pyramid by moving logic to unit tests
📦 Applies To
any
web
🔗 Prerequisites
🔍 Detection Hints
Test suite dominated by E2E tests; full stack spun up for every test; slow flaky CI pipeline >30 minutes
Auto-detectable:
✗ No
playwright
cypress
panther
codeception
⚠ Related Problems
🤖 AI Agent
Confidence: Low
False Positives: Medium
✗ Manual fix
Fix: High
Context: File
Tests: Update