Design and run web test systems with ak:web-testing

Use ak:web-testing to choose and implement a repeatable web-testing strategy, from unit and component tests through browser, visual, accessibility, contract, performance, load, and security checks. It provides detailed reference patterns, a Playwright bootstrap script, and a result summarizer rather than one fixed test suite for every project.

Choose ak:web-testing for repeatable automation

Use ak:web-testing when

• You need project-native Playwright, Vitest, or k6 tests that can run again in local development or CI.
• A feature needs browser, mobile-emulation, visual, accessibility, API, or contract coverage.
• You want to establish Playwright configuration, fixtures, example tests, and report formats.
• You need to diagnose flakiness or select a testing pyramid, trophy, or contract-centric strategy.

Choose another workflow when

• You only need a one-off live browser inspection. Use the runtime's browser workflow rather than creating a test system.
• You need the user's real Chrome cookies or signed-in profile. Use a profile-aware browser workflow; Playwright contexts are isolated by default.
• You need threat modelling or a source security audit. Use ak:security.
• You need general repository test execution without designing web-test infrastructure. Use ak:test.

Prepare the test environment

Before you start:

• Complete Onboarding, and confirm Engineer Kit is installed for the current runtime and scope.
• Provide the test type, target URL or module, expected behavior, browsers or devices, auth method, test data, environment, and cleanup boundary.
• Use Node.js 20 or newer for the declared isolated runtime path.
• Make the selected runners available. Playwright browser binaries, Vitest, k6, axe, Lighthouse, database containers, and optional cloud services are separate dependencies unless the project already provides them.
• Start or explicitly authorize the application server and any database, container, broker, or external test service the suite requires.

Name the test surface explicitly

The Skill declares [test-type] [target], but this release does not define a fixed parser, enumerated values, or a default dispatch for those arguments. State the desired runner and evidence directly.

/ak:web-testing e2e "Test checkout on http://localhost:3000 with Chromium and mobile Safari emulation; use seeded test data and never contact payment production."

/ak:web-testing e2e "Test checkout on http://localhost:3000 with Chromium and mobile Safari emulation; use seeded test data and never contact payment production."

$ak:web-testing e2e "Test checkout on http://localhost:3000 with Chromium and mobile Safari emulation; use seeded test data and never contact payment production."

Use the packaged helper scripts deliberately

Bootstrap Playwright files

The packaged initializer defaults to the current directory. --dir <path> selects a different project, and --ct adds React component-testing configuration.

It creates missing Playwright configuration, E2E fixtures, example tests, global setup, and .env.test.example; it skips files that already exist. It does not install the printed dependencies or browsers. The generated config defaults to http://localhost:3000, runs npm run dev, uses Chromium, Firefox, WebKit, and two mobile emulations, and writes failure artifacts and JSON results. Adapt the sample routes, auth cookie, credentials, package manager, and server command before executing it.

When AGENTKIT_SKILL_RUNTIME=1 is enabled, the declared runtime can isolate @playwright/test@1.48.0 under AgentKit's cache instead of adding it to the project. Browser downloads and the other tools listed on this page remain separate requirements.

Summarize existing results

The analyzer accepts any combination of Playwright JSON, Vitest JSON, and JUnit XML. Output defaults to text; --output json and --output markdown are also supported. --fail-threshold N exits non-zero when the calculated pass rate is below N; its default is 0.

It reports totals, passed, failed, skipped, flaky, duration, suites, and a bounded failure list. No readable result input exits with failure.

Follow an evidence-led test workflow

1. Choose the confidence model. Select unit, integration, contract, component, E2E, or a combination based on the architecture and failure risk.
2. Define isolation. Choose fixtures, seeded factories, worker-specific records, transaction rollback, disposable containers, mocked external services, and cleanup.
3. Configure deterministic execution. Prefer accessible selectors, condition-based waits, fixed viewports, disabled animations, controlled time, stable network responses, and reproducible data.
4. Run the smallest useful layer first. Static and unit checks fail fast; integration, browser, visual, accessibility, performance, and load checks expand only where the requested confidence requires them.
5. Exercise selected environments. Browser projects and mobile emulation cover automation; real Safari, real devices, and provider clouds remain separate evidence when required.
6. Preserve artifacts. Keep traces, videos, screenshots, visual diffs, coverage, JSON, JUnit, Lighthouse, k6, or contract reports needed to explain the conclusion.
7. Report limitations. Failed, skipped, flaky, unavailable, emulated, and externally hosted checks remain distinguishable.

Keep data, load, and security effects controlled

• Do not run vulnerability payloads, DAST scanners, brute-force checks, SSRF probes, or load tests against a system without exact authorization and a safe target. Never aim packaged example payloads at production by default.
• Test credentials belong in approved secret storage. Do not commit real values to .env.test.example, fixtures, snapshots, traces, screenshots, or reports.
• Playwright installation can download browser binaries and system packages. Testcontainers can pull images and start local containers. Both consume disk, network, CPU, memory, and process capacity.
• BrowserStack, Sauce Labs, AWS Device Farm, Pact Broker, Grafana Cloud k6, Lighthouse temporary public storage, Snyk, and similar services can upload code-adjacent data or artifacts and incur provider usage or cost.
• Updating visual snapshots changes the accepted baseline. Review every diff; --update-snapshots is not a repair for an unexplained regression.
• The workflow does not commit, push, open a PR, merge, deploy, or publish test artifacts unless a separate authorized workflow performs that action.

Verify the result

A complete result should include:

• Test strategy, exact scope, target environment, runner versions, browsers, emulations or real devices, and commands executed.
• Passed, failed, skipped, flaky, duration, coverage, thresholds, and build or server status as applicable.
• Failure names, essential error evidence, trace and artifact locations, and reproduction steps.
• Data created, cleanup performed, network services contacted, and any provider or container resources used.
• Accessibility violations, visual diffs, Core Web Vitals, load percentiles, contract results, or security findings only for the selected surfaces.
• Explicit evidence gaps for missing browsers, real devices, auth, tools, permissions, network, or environment parity.

Release testing verifies that the runtime manifest parses and declares a Node runtime with packages. No directly scoped tests were found for the initializer, result analyzer, generated Playwright project, or live browser and provider workflows. Stable and beta package the same ak:web-testing content.

Troubleshoot and interpret limits

Use ak:test for a broader project validation report, or ak:security for threat-modelled source review.