Omar SobhandClaude Opus 5
4358964c05
55 of 85 role skill bindings pointed at skills that were never authored,
so 10 of 11 team templates bound a smaller context bundle than their role
prompts assumed. Three roles bound nothing at all (gpu.bench_engineer,
threejs.shader_author, threejs.perf_engineer) while their prompts described
procedures they had no way to read.
The loader comment at team_template_loader.rs:167 already diagnosed this —
snake_case slugs in TOML against kebab-case skill files — and it was
half-fixed: the kebab names were corrected, the snake_case ones left.
It was invisible because both existing tests assert authored ⊆ referenced
(30/30, green) and the second explicitly declines to check the other
direction. So the failing half was the half nobody asserted.
Resolved every name by one of three explicit choices:
- 23 skills authored where the role genuinely needed the procedure
(gpu, threejs, research, analysis, frontend, mobile, backend, platform)
- renames onto authored skills where one existed in substance, including
the four-near-duplicate cases that collapse onto one real skill
- 22 aspirational references deleted — a binding an agent cannot read is
a promise, not a capability
Two tests now hold it. The unit test checks referenced ⊆ authored against
the files. The new integration test runs both loaders in boot order and
asserts the bindings survive the trip through the database, which is a
different question: resolution goes through skills_catalog rows, so a skill
file that exists but fails to ingest still leaves the role empty.
Negative controls: the unit test failed naming all 55; the integration test
fails naming the exact role when one name is reverted.
threejs.shader_author and .perf_engineer gained a second and third skill
after the collapse — pin_in_context pins idx < 2, so a role left with one
skill silently pins less than the policy intends.
Co-Authored-By: Claude Opus 5 <[email protected]>
61 lines
2.2 KiB
Markdown
61 lines
2.2 KiB
Markdown
---
|
|
name: playwright-e2e-patterns
|
|
description: Writing end-to-end tests that fail only when the product is broken — selectors, waiting, and isolation.
|
|
when_to_use: You are the tester on a frontend team writing or fixing browser tests.
|
|
tags: [frontend, testing]
|
|
---
|
|
|
|
# A flaky E2E test is worse than no E2E test
|
|
|
|
It trains the team to re-run rather than investigate, and the day it catches a
|
|
real bug, nobody believes it. Everything below is about determinism.
|
|
|
|
## Select by what the user sees
|
|
|
|
```ts
|
|
page.getByRole("button", { name: "Save" }) // best
|
|
page.getByLabel("Email")
|
|
page.getByTestId("mission-card") // when semantics genuinely absent
|
|
page.locator(".btn-primary > span:nth-child(2)") // never
|
|
```
|
|
|
|
Role and label selectors survive restyling and break when the UI genuinely
|
|
changes meaning — which is exactly the failure you want. CSS-path selectors
|
|
break on every refactor and pass while the button is invisible.
|
|
|
|
## Never sleep
|
|
|
|
```ts
|
|
await page.waitForTimeout(2000); // flaky, always
|
|
await expect(page.getByText("Saved")).toBeVisible(); // waits for the condition
|
|
```
|
|
|
|
Playwright's assertions retry until timeout. A fixed sleep is either longer than
|
|
needed (slow suite) or shorter than needed on a loaded CI box (flake). There is
|
|
no correct constant.
|
|
|
|
For network, wait on the response rather than a duration:
|
|
```ts
|
|
const done = page.waitForResponse(r => r.url().includes("/api/missions"));
|
|
await page.getByRole("button", { name: "Create" }).click();
|
|
await done;
|
|
```
|
|
|
|
## Each test creates what it needs
|
|
|
|
Tests that share a fixture pass in isolation and fail in parallel — or worse,
|
|
pass in the order you wrote them and fail when one is skipped. Create the data
|
|
in the test, key it with a unique id, and let cleanup be optional.
|
|
|
|
## Assert the user-visible outcome
|
|
|
|
Assert the success message and the row in the table, not the POST that fired.
|
|
A test asserting the request passes while the response is silently discarded —
|
|
which is precisely the bug the test existed to catch.
|
|
|
|
## When a test fails, look at the trace
|
|
|
|
`--trace on` records DOM snapshots, network and console for every step. Reading
|
|
the trace takes a minute and answers the question; re-running takes a minute and
|
|
answers nothing.
|