e2e-test-generator

E2E Test Generator (Playwright)

Role in one line

Takes a reviewed test plan as input and turns it into Playwright code that matches the project's existing test conventions, implementsit, and verifies it through actual execution — that is the Generator.

Why separate planning and implementation

If you hand "what to test + how to write the code + conventions" all at once to a single LLM, all three end up half-baked. This skill focuses on just one thing: implementation .

Premise: what to verify and in what order has already been decided before it arrives. That decision is turned into working code, and it is the Generator's job to take responsibility for behavior and quality gates.

If there is no plan, it stops and says so. It does not invent scenarios by guessing — that is the Planner's job, and mixing it in here would defeat the purpose of the separation.

The new value of this skill

Not browser driver usage, but harness thinking 다. 즉,

codegen output is used only as a starting pointand is not committed as-is — it decides what to refine and what to discard.
Each step of the plan is executed and verified in a real browserwhile the code is written. It does not write selectors based on assumptions alone.
It first learnsthe existing test code and guide documents so that the new code blends naturally into them.
Completion is defined not as "I wrote the code" but as "type/lint pass + actual execution green" .

Browser command syntax (click, type, codegen, saving storageState, running code) is already covered by the playwright-cli skill. It is not repeated here. Open the following when needed:

Record actions with codegen → extract TS code: .codex/skills/playwright-cli/references/test-generation.md
Save/restore storageState (auth separation): .codex/skills/playwright-cli/references/storage-state.md
Run arbitrary Playwright code (run-code) · wait strategies · downloads: .codex/skills/playwright-cli/references/running-code.md
For the index of other commands, see playwright-cli/SKILL.md.

What does it take as input

A reviewed test plan. It usually contains the following.

Scenario title and purpose
List of steps — the order of actions from the user's perspective
Expected result per step (assertion candidates)
Target URL/path, required login state, test data

Whatever form the plan takes — a table, free text, etc. — organize the above items in your head before writing code. If anything is missing, mark it as a gap in the planning stage rather than guessing, and ask the user.

Workflow

Each time you finish a step, self-check with the verification criteria (verify). If the gate (step 5) is red, don't stop—fix the cause and run it again.

1. Learning the conventions (mandatory before writing code)

If a new test is heterogeneous from the existing code, it gets blocked in review and maintenance breaks too. First, read how the project writes tests.

What to look for:

The structure of existing *.spec.ts / *.test.ts — test.describe grouping, test.step whether it's used, step-name language (Korean/English).
playwright.config.ts — testDir, baseURL, projects, storageState, globalSetup.
Authentication handling — login setup project, storageState fixture, shared fixture (test.extend).
Selector conventions — getByRole/getByTestId/data-testid which of these is used.
Test data and helpers — fixtures, factories, seed scripts.
If there is a test-writing guide document (docs/, CONTRIBUTING, .codex/rules/), read it and follow it.

Verification: you can summarize in one sentence the pattern the new file must follow (e.g., "auth uses the storageState fixture, steps are in Korean test.step, selectors prioritize getByRole ").

Detailed checklist: references/convention-discovery.md.

2. Pulling a draft with codegen (starting point)

Run the plan's flow once through in a real browser and recordthe working code. This is faster and more accurate than imagining selectors by hand.

For command usage, playwright-cli/references/test-generation.md.
After each action, snapshot check the page state and see whether the intended change occurred.
Collect the output TS lines. This is a draft. Don't use it as is.

Verification: for each major action in the plan, there is a corresponding generated code line.

3. Restructure to match the conventions (codegen ≠ final)

The codegen output is just a flat list of actions, missing structure, authentication, and verification. Refine it using the patterns learned in step 1.

Separate authentication from the body. Instead of inlining the login step in every test, move it to a storageState fixture / setup project. Rationale and pattern: references/storage-state.md + references/auth-fixture.md.
test.step Separate steps with Wrap each step of the plan in a single test.step so the failure location shows up in the report.
Step names follow the project language. For this project's presentation deliverable, the standard is Korean step names(예: await test.step('로그인 후 대시보드 진입', ...)).
Selector promotion. Replace codegen's fragile selectors with the project conventions (role/testid).
Add initialization logic. Explicitly set up the prerequisite state the plan assumes, such as login, seed data, and feature flags.
Add assertions. codegen captures only actions. Move the plan's expected results into expect .

Target skeleton and before/after example: references/test-structure.md.

Verification: the file matches the step 1 summary pattern, and every plan step is expressed as test.step + expect .

4. Step-by-step execution verification

While writing (or immediately after), verify in the browser that the step actually passes. "The code looks plausible" is not evidence of passing.

Run the scenario once all the way through to see whether the flow gets blocked.
If blocked, isolate just that step and run-code inspect with (references/running-code.md).
Selector misses and timing issues are caught here. If unstable, fix with explicit waits/expect automatic retries.

Verification: the scenario passes from start to finish without human intervention.

5. Quality gates (definition of done)

It is complete only when the following are all green. If even one is red, fix it and run again.

# 1) 타입
yarn type-check        # 없으면: npx tsc --noEmit

# 2) 린트 (새 파일 경로 지정)
yarn lint              # 또는: npx eslint <new-spec-path>

# 3) 실제 테스트 실행 — green 이어야 함
npx playwright test <new-spec-path>

For type-check / lint, prefer the project scripts; if none, use the fallback above.
If the test run is red, the test may be telling the truth(app bug), or it may be a selector/wait issue. Distinguish and handle accordingly, and if an app bug is suspected, do not force the code to pass—report it.
Gate operation details: references/quality-gates.md.

Verification: all three commands pass, and their output proves completion.

Output

Following project conventions, *.spec.ts file(s).
If needed, storageState/auth fixtures or a setup project.
Evidence of passing the 3 gates (summary of command output).

Position in the pipeline

This Generator is one step in the E2E pipeline. The steps before and after are handled by other skills.

Before (planning): e2e-flow-planner creates a plan specifying what and why to test → this skill takes that output as input.
After (hardening): removing flakiness, ensuring independence, and strengthening mocking for the generated tests is e2e-test-hardener.
After (healing): diagnosing and fixing with trace when an existing test breaks is e2e-test-healer.

If the incoming request is actually for an adjacent step (no plan / fix existing tests), point to that side and do not force this skill's new-generation workflow onto it.

Do not do

Do not arbitrarily add scenarios not in the plan (scope creep, encroaching on the Planner's area).
Do not commit codegen output as-is without structure or verification.
Do not weaken or delete assertions just to pass — that makes the test lie.
Do not hardcode auth secrets in code or commit storageState files.
Do not drag this workflow into requests that only need simple browser manipulation/screenshots — playwright-cli is enough.