本文へ移動
cccskills
無料GitHub で公開

playwright-fixture-builder

Builds reusable Playwright fixtures via `test.extend` - picks the right scope (test vs worker), wires the `use(value)` setup/teardown split, composes auth (storageState per worker), database (per-test snapshot/restore), and feature-flag fixtures into one custom `test` object the whole suite imports. Outputs the `fixtures.ts` file plus per-fixture review notes (scope rationale, teardown ordering, `workerInfo.workerIndex` for parallel isolation). Use when the suite has copy-pasted `beforeEach` boilerplate that should be a fixture, or when adding auth / db / flag setup that crosses many specs.

日本語の概要は準備中です。原文の説明を表示しています。

testland/qaスター 13(GitHub 13 + cccskills 0)
連携ツールPlaywright

実行スコア 未検証

インストール方法を見る

含まれるファイル(5)

  • SKILL.md7.6 KB
  • .tessl-plugin/plugin.json739 B
  • references/anti-patterns-and-limits.md3.0 KB
  • references/composition-and-output.md2.9 KB
  • references/fixture-recipes.md4.8 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

playwright-fixture-builder

Overview

Playwright Test fixtures replace beforeEach / afterEach boilerplate with composable, lazy-initialized values that hang off the test function (pw-fixtures).

This skill is build-an-X - it produces the fixtures.ts (or language-equivalent) file from the team's actual setup needs (auth, database state, feature flags, app instance), picking the right scope and teardown ordering for each.

When to use

  • Multiple spec files copy-paste beforeEach/afterEach setup blocks that should be a fixture.
  • A new test suite needs auth + DB + flags wired and the team wants one cohesive fixtures.ts rather than ad-hoc helpers.
  • An existing suite is slow because each test re-authenticates; there's a worker-scope shortcut available.
  • The team is adding parallelism and current fixtures don't honor workerInfo.workerIndex for per-worker isolation.

If the suite has only a handful of specs and one common helper, a shared helpers.ts file is enough - fixtures pay off when 5+ specs share setup or when teardown ordering matters.

How to use

  1. List every beforeEach/afterEach block the specs share (auth, DB reset, flag setup, page objects).
  2. Assign each a scope with Step 1's rule of thumb - worker for immutable expensive state, test for anything that changes between tests.
  3. Write each fixture with the use(value) setup/teardown split - recipes for auth, page object, DB, and flags are in references/fixture-recipes.md.
  4. Compose them in dependency order (auth → db → flags) into one test export; see references/composition-and-output.md.
  5. Confirm teardown runs in reverse of setup, and box internal helper fixtures out of the report.
  6. Replace the specs' copy-pasted blocks with a single import from the composed fixtures/index.ts.
  7. Emit the per-fixture review note (scope, auto, boxed, setup cost, teardown) so a reviewer can sanity-check the scoping.

Step 1 - Identify the right scope per fixture

Fixtures are test-scoped by default (run and torn down per test); declare { scope: 'worker' } for state shared across a worker's tests (pw-fixtures). The table assigns a scope per fixture.

FixtureScopeWhy
Authenticated userworkerAuth handshake is expensive (UI login, cookie set, OTP); state is shareable.
Storage-state file pathworkerOne storageState per worker keeps server-side cohorts isolated.
Page object (TodoPage)testEach test needs a clean DOM and navigation start.
Test-DB snapshottestPer-test isolation requires per-test restore.
Feature-flag overridestestDifferent tests may want different flag combos (compose with feature-flag-test-harness).
Browser instanceworker(Playwright default) - sharing cuts ~500ms per test.
Test-data factorytestEach test gets fresh fixtures with worker-namespaced IDs.

Rule of thumb: if changing the fixture between two tests would cause a test to fail, scope it test. Otherwise scope it worker.

Fixture recipes, composition, output

A complete worker-scoped storageState auth fixture - signs in once per worker and reuses the cookie / localStorage snapshot across that worker's tests:

// fixtures/auth.ts
import { test as base } from '@playwright/test';
import path from 'node:path';

export const test = base.extend<{}, { storageState: string }>({
  storageState: [async ({ browser }, use, workerInfo) => {
    const username = `user${workerInfo.workerIndex}`;
    const fileName = path.resolve(`playwright/.auth/${username}.json`);

    const page = await browser.newPage({ storageState: undefined });
    await page.goto('/login');
    await page.getByLabel('Email').fill(`${username}@example.com`);
    await page.getByLabel('Password').fill('test-password');
    await page.getByRole('button', { name: 'Sign in' }).click();
    await page.waitForURL('/dashboard');

    await page.context().storageState({ path: fileName });
    await page.close();
    await use(fileName);
  }, { scope: 'worker' }],
});

Worked example

A suite of 12 checkout specs each opens with the same beforeEach: log in through the UI, reset the test DB, then set a feature flag. That block re-authenticates once per test, so the run spends ~12s just logging in.

Refactor it into four fixtures. storageState moves to worker scope keyed by user${workerInfo.workerIndex}, so each worker logs in once (~1.2s) instead of every test. cleanDb is test-scoped with { auto: true } so every spec starts from a restored snapshot without listing it. flags is test-scoped and restores an empty provider on teardown so a leaked override can't poison the next test. todoPage stays test-scoped because the page object holds per-test state.

They compose auth → db → flags in fixtures/index.ts; each spec now imports { test, expect } from there and drops its beforeEach. A checkout test becomes async ({ page, flags, cleanDb }) => { await flags({ promo_codes: true }); ... }. The per-fixture review note records that worker-scoped auth cut ~600ms × 12 tests and that flags teardown is what keeps combinations isolated.

Anti-patterns and limitations

The full anti-pattern table (wrong-scope fixtures, beforeAll in a parallel suite, manual context.close(), committing auth files, one mega-fixture) and the limitations (no mid-test scope changes, session storage not auto-captured, teardown failures don't fail the test, per-fixture timeout) are in references/anti-patterns-and-limits.md.

References

  • pw-fix - test.extend, scope (test vs worker), workerInfo.workerIndex, automatic / boxed fixtures, default fixtures.
  • pw-auth - storageState pattern, per-worker authentication via parallelIndex, role-based auth files, security note on .gitignore.
  • feature-flag-test-harness - the matrix-shard pattern that complements per-test flags fixture overrides.
  • testcontainers, docker-compose-tests - the underlying stack the fixtures point at.

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

コメント

ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。

まだコメントはありません。最初のコメントを書いてみませんか。

送信するとすぐに公開されます。メールアドレスや電話番号などの個人情報は書かないでください。URL は 2 つまでです。

0 / 1000 文字

このフォームは reCAPTCHA で保護されており、Google のプライバシーポリシーと利用規約が適用されます。

同じリポジトリのスキル

Builds a CI gate that fails the build on **new** WCAG / a11y violations introduced by a PR while grandfathering pre-existing violations on a per-rule / per-page baseline. Aggregates verdicts from axe-core / pa11y / Lighthouse a11y / WAVE / IBM Equal Access scans. Use when a project has accumulated a11y debt and a strict "zero violations" gate would block every PR - the ratchet pattern lets the team ship while preventing regressions.

日本語の概要は準備中です。原文の説明を表示しています。

testland/qa132026年10月20日 更新

Workflow skill that builds an A/B-test validity checklist from an experiment proposal, walking the canonical design-correctness gates - pre-registered OEC/power/guardrails, randomization unit + SRM check, assignment integrity, telemetry, peeking discipline, novelty/primacy, post-experiment SRM re-check - into a per-experiment checklist + sign-off form. Use when launching, auditing, or governing an experiment. For pitfall mechanics (guardrails, peeking) see experiment-results-interpreter's references; to read an already-valid result use experiment-results-interpreter; for per-SDK harness tests use experiment-sdk-testing - this gates DESIGN, not SDK code.

日本語の概要は準備中です。原文の説明を表示しています。

testland/qa132026年10月20日 更新

The single install-flow skill: the reference contract for the PWA install flow (installability gate fields, `beforeinstallprompt` handshake, per-platform paths - Android WebAPK / iOS Share menu / Firefox no-op - and the `display-mode` post-install signal, in references/install-flow-reference.md) plus the build-an-X workflow that emits the Add-to-Home-Screen suite. Walks the four-stage timeline, emitting one test per gate cell per [web.dev/articles/install-criteria][install-criteria], the deferred-prompt → `prompt()` → `userChoice` chain per [web.dev/articles/customize-install][customize-install], the iOS Safari manual-metadata branch (`apple-touch-icon`) per [web.dev/learn/pwa/installation][learn-pwa], and the post-install `(display-mode: standalone)` MQ assertion. Output: a Playwright spec with per-stage cells plus a coverage matrix. Use when a PWA's manifest, icons, or install handler change, when install conversion drops at an unknown stage, or when triaging a flaky install assertion.

日本語の概要は準備中です。原文の説明を表示しています。

testland/qa132026年10月20日 更新

Build-an-X workflow that uses an LLM to map existing tests to spec sections - given a spec doc + the test suite, the LLM identifies which tests cover which sections, surfaces uncovered sections (gap), and recommends specific tests to add. Output is a coverage matrix per spec ID. Scope is mapping tests that already exist and naming the gaps, not authoring tests for new acceptance criteria. Use when a spec doc and a test suite both exist but nobody can say which requirements are actually covered - before a release sign-off, an audit, or a decision about where to spend the next round of test effort.

日本語の概要は準備中です。原文の説明を表示しています。

testland/qa132026年10月20日 更新

Generates tests from natural-language specs (acceptance criteria, user stories, requirements) using an LLM, with confidence scoring per test case (LLM self-assessment plus heuristics: assertion quality, naming, completeness), batching uncertain cases for human review, and integration with the team's existing test framework. Use when the user asks to generate unit tests from acceptance criteria, convert user stories to test cases, automate test creation from requirements, or augment a spec-driven test suite with AI-generated stubs that are then curated before merge.

日本語の概要は準備中です。原文の説明を表示しています。

testland/qa132026年10月20日 更新

Configures Allure Report (test-runner adapter install, `allure-results` directory wiring, `categories.json` for failure classification, `history-trend.json` retention via the copy-history-between-runs pattern), runs the Allure CLI to convert `allure-results` to a static HTML site, and uploads the report as a CI artifact. Use when the team needs richer test reporting than JUnit XML - step-level attachments, per-test history, retry tracking, and severity / epic / feature labeling across framework-agnostic adapters (pytest, Jest, JUnit, TestNG, NUnit, Mocha). As a rich static HTML report generator, it is the open-source alternative to the sunset ExtentReports (JVM/.NET per-test HTML narrative); for hosted cross-run flakiness analytics rather than a static per-run report use currents-integration.

日本語の概要は準備中です。原文の説明を表示しています。

testland/qa132026年10月20日 更新

testland のスキルをすべて見る

このスキルの問題を報告する