Test Generator
Diese Fähigkeit generiert entweder Vitest-Einheitstests für eine angegebene Datei oder Playwright-E2E-Tests für einen Benutzerfluss. Sie analysiert vorhandenen Code und Konventionen, um relevante Testfälle zu erstellen.

Was es macht
Generiert Softwaretests. Für einen angegebenen Dateipfad erstellt es Vitest-Einheitstests, analysiert Exporte, Abhängigkeiten und bestehende Testmuster, um die Abdeckung zu gewährleisten. Wenn es mit e2e und einer Flow-Beschreibung aufgerufen wird, generiert es Playwright-End-to-End-Tests, die kritische Benutzerflüsse und die Anwendungsstruktur identifizieren.
Wann du es einsetzt
Nutze diese Fähigkeit, wenn du schnell Einheitstests zu neuen oder bestehenden Dateien hinzufügen oder umfassende E2E-Tests für Benutzerflüsse in deiner Anwendung erstellen musst. Es hilft dir, die Codequalität sicherzustellen und das Anwendungsverhalten in verschiedenen Szenarien zu überprüfen.
So richtest du es ein
Kopiere zuerst die Definition dieses Skills in .claude/skills/test-gen/SKILL.md in dein Repository. Um Vitest-Einheitstests für eine Datei zu generieren, rufe es mit /test-gen [Dateipfad] auf, zum Beispiel /test-gen src/utils/math.ts. Um Playwright-E2E-Tests für einen Benutzerfluss zu generieren, verwende /test-gen e2e [Flussbeschreibung], zum Beispiel /test-gen e2e Anmeldeablauf.
Der Inhalt
Test Generator
Generate tests for the given target.
Mode selection: If $0 is the literal token e2e, skip to the
E2E Mode (Playwright) section at the bottom. Otherwise generate Vitest
unit tests for the file per Steps 1–7 below.
Target: $ARGUMENTS
Test framework: !cat package.json 2>/dev/null | grep -o '"vitest"' | head -1 || echo "vitest not found"
Existing tests: !find src -name "*.test.ts" -o -name "*.test.tsx" -o -name "*.spec.ts" -o -name "*.spec.tsx" 2>/dev/null | head -10 || echo "none found"
Step 1: Analyze the Target File
Read $ARGUMENTS and extract:
- All exported functions, classes, components, and types
- Dependencies and imports (what needs mocking)
- Side effects (API calls, database queries, file system access)
- Input parameter types and return types
Step 2: Check for Existing Tests
Search for existing test files:
<filename>.test.ts/<filename>.test.tsx<filename>.spec.ts/<filename>.spec.tsx__tests__/<filename>.ts
If tests exist, read them and only add missing coverage. Do NOT duplicate existing test cases.
Step 3: Identify Test Cases
For each export, determine:
| Category | What to test |
|---|---|
| Happy path | Normal input produces expected output |
| Edge cases | Empty input, null/undefined, boundary values |
| Error paths | Invalid input, thrown errors, rejected promises |
| Async | Promise resolution/rejection, timeout behavior |
| Dependencies | Mock external calls (API, DB, third-party libs) |
Step 4: Follow Existing Conventions
If existing test files were found in Step 2, match their:
- Import style (
import { describe } from 'vitest'vs global) - Mock patterns (
vi.mock,vi.fn,vi.spyOn) - File naming convention (
.test.tsvs.spec.ts) - Describe/it block structure
- Assertion style (
expect().toBe(),expect().toEqual())
If no existing tests, use this default structure:
import { describe, it, expect, vi, beforeEach } from 'vitest';
Step 5: Generate Tests
Write the test file next to the source file (e.g., src/utils/calc.ts -> src/utils/calc.test.ts).
Rules:
- One
describeblock per exported function/component - Descriptive test names:
it('returns empty array when input is empty') - Arrange-Act-Assert pattern in each test
- Mock external dependencies, never call real APIs/DB
- Test the public interface, not implementation details
- For React components: use
@testing-library/reactif available, otherwise test logic only
Step 6: Verify
Run the generated tests:
npx vitest run <test-file-path> --reporter=verbose
If tests fail:
- Read the error output
- Fix the test (not the source code)
- Re-run until all pass
Step 7: Summary
Output:
- Number of test cases generated
- Coverage areas: happy path, edge cases, error paths
- Any exports that were NOT tested (and why)
- Test run result: PASS / FAIL
E2E Mode (Playwright)
Invoked as /test-gen e2e [flow description]. The remaining arguments after
e2e describe the user flow to test (e.g. /test-gen e2e login flow). If no
flow is given, generate tests for all critical paths (priority below).
E2E Step 1: Understand the Application
Identify:
- Routing setup (Next
app/routes or react-router config) - Authentication flow (login page, auth guards)
- Main user-facing pages, form components and their validation
- API calls made during user flows
cat package.json | grep -o '"@playwright/test"' || echo "Playwright not installed"
ls playwright.config.* 2>/dev/null || echo "No Playwright config"
ls e2e/ tests/e2e/ tests/ 2>/dev/null | head -20
If Playwright is not installed:
npm install -D @playwright/test && npx playwright install chromium
E2E Step 2: Identify Critical User Flows
If no specific flow requested, prioritize:
- Authentication — sign up, login, logout, password reset
- Core CRUD — create, read, update, delete main entities
- Navigation — landing page → key features → back
- Error states — invalid form submission, 404 pages, unauthorized access
- Payment/checkout — if applicable
E2E Step 3: Analyze Page Structure
For each page: read the component file, identify interactive elements,
find data-testid attributes or accessible roles, trace triggered API
calls, identify loading/success/error states.
E2E Step 4: Generate Tests
Create test files in the project's E2E directory (usually e2e/ or
tests/e2e/). Follow Playwright best practices:
- Prefer accessible selectors:
page.getByRole(),page.getByText(),page.getByTestId() page.waitForURL()for navigation,expect(page).toHaveURL()for route verificationawait expect(locator).toBeVisible()overwaitForSelector- Group related tests in
test.describe()blocks test.beforeEach()for common setup (login, navigation)- If a
storageStateauth fixture exists, use it for authenticated flows; otherwise log in via UI inbeforeEach
Each test must assert meaningfully: URL changed, expected content visible, form feedback shown, data persists after reload where applicable.
E2E Step 5: Verify
npx playwright test <test-file> --reporter=list 2>&1
If tests fail: read the error output, fix the test (selectors, timing, assertions), re-run until passing.
E2E Step 6: Summary
Output:
- Files generated and flows covered
- Selector breakdown (roles / test IDs / text)
- Test run result: PASS / FAIL / SKIP with reasons
- Missing coverage and recommended
data-testidadditions
Kommt direkt aus dem Framework, mit dem diese Seite gebaut wird. Diese Seite zeigt immer die aktuelle Version.
Sowas für dich bauen?
Es beginnt mit einem Gespräch: 30 Minuten, unverbindlich.