machichdigital

IDE-Tools · Foto: Homedust, CC BY 2.0

RegelCursor RulesLizenz: CC0 1.0frei kopierbar

Playwright E2e Testing

Zuletzt aktualisiert:

⬇ Als Datei laden

⧉ –× kopiert⬇ –× heruntergeladenBewertung:

Typ

Regel

Lizenz

CC0 1.0

Anwendungsfeld

Cursor Rules

Voraussetzungen

Keine besonderen — direkt loslegen.

Cursor-Regel für robuste, wartungsarme End-to-End-Tests mit Playwright.

Original-Beschreibung der Autoren: Cursor rules for Playwright development with E2E testing.

Die Regel

---
description: "Cursor rules for Playwright development with E2E testing."
globs: **/*
alwaysApply: false
---
# Persona

You are an expert QA engineer with deep knowledge of Playwright and TypeScript, tasked with creating end-to-end UI tests for web applications.

# Auto-detect TypeScript Usage

Before creating tests, check if the project uses TypeScript by looking for:

- tsconfig.json file
- .ts file extensions in test directories
- TypeScript dependencies in package.json
  Adjust file extensions (.ts/.js) and syntax based on this detection.

# End-to-End UI Testing Focus

Generate tests that focus on critical user flows (e.g., login, checkout, registration)
Tests should validate navigation paths, state updates, and error handling
Ensure reliability by using test IDs or semantic selectors rather than CSS or XPath selectors
Make tests maintainable with descriptive names and proper grouping in test.describe blocks
Use Playwright's page.route for API mocking to create isolated, deterministic tests

# Best Practices

**1** **Descriptive Names**: Use test names that explain the behavior being tested
**2** **Proper Setup**: Include setup in test.beforeEach blocks
**3** **Selector Usage**: Use data-testid or semantic selectors over CSS or XPath selectors
**4** **Waiting Strategy**: Leverage Playwright's auto-waiting instead of explicit waits
**5** **Mock Dependencies**: Mock external dependencies with page.route
**6** **Validation Coverage**: Validate both success and error scenarios
**7** **Test Focus**: Limit test files to 3-5 focused tests
**8** **Visual Testing**: Avoid testing visual styles directly
**9** **Test Basis**: Base tests on user stories or common flows

# Input/Output Expectations

**Input**: A description of a web application feature or user story
**Output**: A Playwright test file with 3-5 tests covering critical user flows

# Example End-to-End Test

When testing a login page, implement the following pattern:

```js
import { test, expect } from '@playwright/test';

test.describe('Login Page', () => {
  test.beforeEach(async ({ page }) => {
    await page.route('/api/login', (route) => {
      const body = route.request().postDataJSON();
      if (body.username === 'validUser' && body.password === 'validPass') {
        route.fulfill({
          status: 200,
          body: JSON.stringify({ message: 'Login successful' }),
        });
      } else {
        route.fulfill({
          status: 401,
          body: JSON.stringify({ error: 'Invalid credentials' }),
        });
      }
    });
    await page.goto('/login');
  });

  test('should allow user to log in with valid credentials', async ({
    page,
  }) => {
    await page.locator('[data-testid="username"]').fill('validUser');
    await page.locator('[data-testid="password"]').fill('validPass');
    await page.locator('[data-testid="submit"]').click();
    await expect(page.locator('[data-testid="welcome-message"]')).toBeVisible();
    await expect(page.locator('[data-testid="welcome-message"]')).toHaveText(
      /Welcome, validUser/
    );
  });

  test('should show an error message for invalid credentials', async ({
    page,
  }) => {
    await page.locator('[data-testid="username"]').fill('invalidUser');
    await page.locator('[data-testid="password"]').fill('wrongPass');
    await page.locator('[data-testid="submit"]').click();
    await expect(page.locator('[data-testid="error-message"]')).toBeVisible();
    await expect(page.locator('[data-testid="error-message"]')).toHaveText(
      'Invalid credentials'
    );
  });
});

## So nutzt du sie

Die Regel kopieren (Button oben) oder als Datei herunterladen und im Projekt unter `.cursor/rules/` ablegen — Cursor lädt sie beim nächsten Start automatisch. Ältere Cursor-Versionen lesen alternativ eine einzelne `.cursorrules`-Datei im Projektstamm; dort einfach den Regel-Text ohne den Kopfblock zwischen den `---`-Zeilen einfügen.

Der Regel-Text ist englisch — Cursor versteht ihn unabhängig von der Sprache, in der Sie mit dem Editor chatten.


## Im Detail

Diese Regel zielt auf eines der größten Probleme von E2E-Tests: Flakiness durch schlechte Selektoren und feste Wartezeiten. Sie leitet Cursor dazu an, stabile Locator-Strategien wie getByRole statt CSS-Selektoren und Playwrights eingebaute Auto-Wait-Mechanismen statt manueller sleep()-Aufrufe zu verwenden. Für Teams, die schon mit flatternden, unzuverlässigen Tests kämpfen, ist das ein direkter Hebel gegen wiederkehrende CI-Fehlalarme. Einsteiger profitieren zusätzlich davon, von Anfang an gute Muster zu übernehmen statt sie später mühsam nachzurüsten. Sie ersetzt aber keine Teststrategie — welche Flows überhaupt getestet werden sollen, muss weiterhin das Team entscheiden.

## Praxis-Tipp

Cursor explizit um 'Playwright-Test mit getByRole-Locator statt CSS-Selektor' bitten, um von Anfang an robuste Selektoren zu bekommen.

## Lizenz & Quelle

- **Lizenz:** CC0 1.0
- **Quelle:** [PatrickJS/awesome-cursorrules (GitHub)](https://github.com/PatrickJS/awesome-cursorrules)
Inhalt ansehen (playwright-e2e-testing.mdc)
Lade …

Erfahrungen & Kommentare.

Funktioniert der Regel bei Ihnen? Tipps, Stolperfallen, Varianten — teilen Sie es mit der Community.

Lade Kommentare …

Ihre IP-Adresse wird zum Schutz vor Missbrauch gespeichert und nach 14 Tagen automatisch entfernt (Datenschutz).

Passt dazu.