원클릭으로
playwright-network-mocking
Playwright workflows for deterministic third-party responses using page.route().
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Playwright workflows for deterministic third-party responses using page.route().
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
Playwright workflows for authenticated browser state reuse through storageState and setup projects.
Conducts rigorous authoring and review of Playwright E2E tests. Enforces accessibility-first locators, web-first assertions, strict isolation, and DAMP architecture. Use when generating, refactoring, or reviewing any Playwright test code.
Diagnostic Playwright workflows for flaky or failing tests, including trace analysis, UI mode, and state isolation.
SOC 직업 분류 기준
| name | playwright-network-mocking |
| description | Playwright workflows for deterministic third-party responses using page.route(). |
Use this skill when a test depends on a slow, unreliable, or external service and you need deterministic responses without hitting the real provider. It lets you isolate the boundary that matters while keeping the rest of the application real.
Do not use this skill when the real third-party integration is the feature under test, or when the app is already local and deterministic without request interception.
playwright-debugging instead.Use page.route() to replace external responses with deterministic data before the page makes the request.
import { test, expect } from '@playwright/test';
test('shows premium dashboard when billing is active', async ({ page }) => {
await page.route('**/api/v1/billing/status', async route => {
await route.fulfill({
status: 200,
json: {
subscription: 'active',
plan: 'premium',
},
});
});
await page.goto('/dashboard');
await expect(page.getByRole('heading', { name: 'Welcome to Premium' })).toBeVisible();
});
Intercept only the unstable boundary and leave the rest of the application real. If the code under test makes several external calls, mock the minimum necessary surface area.
Prefer page.route() when the response is part of the behavior under test and must be controlled from the browser context. If you need broader, suite-wide control, consider a fixture or a backend test double instead of scattering route handlers through individual tests.
Verify the intercepted request produces the expected UI and that the real service is not required for the test to pass.
Typical checks:
npx playwright test tests/dashboard.spec.ts
Use trace viewer or UI mode to confirm the mocked response is the one the app consumed.