e2e-testing

Runs and creates end-to-end API and frontend tests after every PR and code push.

7|12|Updated Mar 26, 2026
One-click install
npx skills add https://github.com/OpenRouterTeam/docs --skill e2e-testing-openrouterteam
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: e2e-testing
Source: https://github.com/OpenRouterTeam/docs/tree/main/.agents/skills/e2e-testing
Command: npx skills add https://github.com/OpenRouterTeam/docs --skill e2e-testing-openrouterteam

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code changes pushed without verification lead to broken APIs, regressions, and UI bugs reaching users. This Skill enforces a mandatory testing discipline: after every PR creation and every subsequent behavior-changing push, it runs the relevant end-to-end tests, creates new tests for uncovered changes, and refuses to report completion when testing failed or was skipped. ## Core Features & Use Cases - API E2E Testing: Runs Vitest-based suites in tests/e2e/ against the local stack, using a deterministic fake-provider upstream, shared request builders, model groups, and Zod schema assertions, with dev-fs-logs inspection for evidence. - Frontend Video Verification: Records browser sessions of affected pages, reviews the recording for bugs, fixes issues, and re-records until the video demonstrates everything working. - Mandatory Test Creation: Creates regression or feature tests for any change lacking coverage, choosing between CI-run e2e tests and manual tests for expensive or investigative scenarios. - Use Case: After fixing a streaming bug in a provider adapter, run the relevant chat-completions e2e suite against the local fake-provider, inspect dev-fs-logs for the generation, add a regression test, and only then report the PR as ready. ## Quick Start Ask the AI to run the relevant e2e tests for your PR changes and create new tests for any uncovered behavior before reporting completion.

Frequently Asked Questions about e2e-testing

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I run end-to-end API tests locally?▼

Start the local stack with the local-dev-env workflow, wait for fake-provider to be ready, then run `cd tests/e2e && bun run test:e2e run <path-to-test>`. The harness defaults to TEST_ENV=local with the seeded unlimited API key against http://127.0.0.1:8787.

How do I test frontend changes with browser recording?▼

Sign in to the local web app, start a screen recording with whatever browser tool is available (Playwright MCP, built-in browser, or preview), navigate affected pages, and annotate assertions. Review the recording for failures, fix any bugs, and re-record until everything works.

When should I use manual tests instead of e2e tests?▼

Use tests/manual/ for expensive real API calls, flaky provider-dependent behavior, or bug reproduction documentation that should not run in CI. Default to tests/e2e/ for cheap, deterministic tests that validate core API behavior on every PR.

How do I make API tests deterministic without real providers?▼

Run the use-local-fake-provider script after the stack starts, then request the seeded model with provider order restricted to fake-provider and fallbacks disabled. This routes traffic to a controllable local upstream with deterministic responses.

Why are dev-fs-logs empty after running my tests?▼

dev-fs-logs writes one directory per inference generation only. Changes on non-inference routes like auth middleware or credits endpoints leave the logs empty, so use the worker request log from tilt logs api as evidence instead.

What should I do when e2e tests fail after a code push?▼

Investigate the failure using test output and dev-fs-logs, fix the root cause, and re-run the tests before reporting. Never report a PR as ready when testing failed or was skipped, and avoid pushing multiple untested fixes in a row.