E2E Testing Patterns

Test what users do, not how code works. E2E tests prove the system works as a whole — they're your confidence to ship.

Installation

OpenClaw / Moltbot / Clawbot

CODEBLOCK0

---

WHAT This Skill Does

Provides patterns for building end-to-end test suites that:

• - Catch regressions before users do
• Run fast enough for CI/CD
• Remain stable (no flaky failures)
• Cover critical user journeys without over-testing

WHEN To Use

• - Implementing E2E test automation for a web application
• Debugging flaky tests that fail intermittently
• Setting up CI/CD test pipelines with browser tests
• Testing critical user workflows (auth, checkout, signup)
• Choosing what to test with E2E vs unit/integration tests

---

Test Pyramid — Know Your Layer

CODEBLOCK1

What E2E Tests Are For

E2E Tests ✓	NOT E2E Tests ✗
Critical user journeys (login → dashboard → action → logout)	Unit-level logic (use unit tests)
Multi-step flows (checkout, onboarding wizard)

API contracts (use integration tests) | | Cross-browser compatibility | Edge cases (too slow, use unit tests) | | Real API integration | Internal implementation details | | Authentication flows | Component visual states (use Storybook) |

Rule of thumb: If it would devastate your business to break, E2E test it. If it's just inconvenient, test it faster with unit/integration tests.

---

Core Principles

Principle	Why	How
Test behavior, not implementation	Survives refactors	Assert on user-visible outcomes, not DOM structure
Independent tests

Parallelizable, debuggable | Each test creates its own data, cleans up after |
| Deterministic waits | No flakiness | Wait for conditions, not fixed timeouts |
| Stable selectors | Survives UI changes | Use data-testid, roles, labels — never CSS classes |
| Fast feedback | Developers run them | Mock external services, parallelize, shard |

---

Playwright Patterns

Configuration

CODEBLOCK2

Pattern: Page Object Model

Encapsulate page logic. Tests read like user stories.

CODEBLOCK3

Pattern: Fixtures for Test Data

Create and clean up test data automatically.

CODEBLOCK4

Pattern: Smart Waiting

Never use fixed timeouts. Wait for specific conditions.

CODEBLOCK5

Pattern: Network Mocking

Isolate tests from real external services.

CODEBLOCK6

---

Cypress Patterns

Custom Commands

CODEBLOCK7

Network Intercepts

CODEBLOCK8

---

Selector Strategy

Priority	Selector Type	Example	Why
1	Role + name	INLINECODE1	Accessible, user-facing
2

Label | getByLabel("Email address") | Accessible, semantic |
| 3 | data-testid | getByTestId("checkout-form") | Stable, explicit for testing |
| 4 | Text content | getByText("Welcome back") | User-facing |
| ❌ | CSS classes | .btn-primary | Breaks on styling changes |
| ❌ | DOM structure | div > form > input:nth-child(2) | Breaks on any restructure |

CODEBLOCK9

---

Visual Regression Testing

CODEBLOCK10

---

Accessibility Testing

CODEBLOCK11

---

Debugging Failed Tests

CODEBLOCK12

CODEBLOCK13

---

Flaky Test Checklist

When a test fails intermittently, check:

Issue	Fix
Fixed waitForTimeout() calls	Replace with waitForSelector() or expect assertions
Race conditions on page load

Wait for networkidle or specific elements |
| Test data pollution | Ensure tests create/clean their own data |
| Animation timing | Wait for animations to complete or disable them |
| Viewport inconsistency | Set explicit viewport in config |
| Random test order issues | Tests must be independent |
| Third-party service flakiness | Mock external APIs |

---

CI/CD Integration

CODEBLOCK14

---

NEVER Do

1. 1. NEVER use fixed waitForTimeout() or cy.wait(ms) — they cause flaky tests and slow down suites
2. NEVER rely on CSS classes or DOM structure for selectors — use roles, labels, or data-testid
3. NEVER share state between tests — each test must be completely independent
4. NEVER test implementation details — test what users see and do, not internal structure
5. NEVER skip cleanup — always delete test data you created, even on failure
6. NEVER test everything with E2E — reserve for critical paths; use faster tests for edge cases
7. NEVER ignore flaky tests — fix them immediately or delete them; a flaky test is worse than no test
8. NEVER hardcode test data in selectors — use dynamic waits for content that varies

---

Quick Reference

Playwright Commands

CODEBLOCK15

Cypress Commands

CODEBLOCK16