Install any skill in seconds. Free to start, no credit card required.
Get Started Free →camunda/frontend-integration-test
Use when writing, modifying, or debugging Playwright tests in the orchestration cluster webapp — integration tests, visual regression, or accessibility tests; MSW mocking, Page Object Models, or axe-core. Test directory: webapp/client/apps/orchestration-cluster-webapp/test/.
Passed 21 of 22 test cases with the skill, and 5 of 22 without it.
and 20 more in the full report
16 fixed5 passed either way1 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 16 test cases the skill fixed. Same model, same prompt, with and without the skill.
Provide the CLI commands to run integration tests, visual regression tests, and accessibility tests for `@camunda/orchestration-cluster-webapp`.
| Checked | Without skill | With skill |
|---|---|---|
| Specifies npm run test:integration for integration testing. | Missed | Passed |
| Specifies npm run test:visual for visual regression testing. | Missed | Passed |
| Specifies npm run test:a11y for accessibility testing. | Missed | Passed |
The instructions your model reads when the skill loads.
Playwright tests in @camunda/orchestration-cluster-webapp cover three categories — integration, visual regression, and accessibility — across 7 Playwright projects. Tests run against the built app served by vite preview on port 3003. MSW intercepts HTTP at the network level via @msw/playwright, so no real backend is needed.
Each test() spins up a fresh browser context and every goto() reboots the full SPA bundle plus MSW
interception. Page loads are the dominant Playwright cost — structure tests to minimize them.
Scope each test to one feature (observable behavior), not to one assertion and not to an entire page.
A feature test should:
Do not split a feature into multiple tests just to isolate individual assertions. A test named "should show the info sidebar links" should assert every expected link in one go, not spawn four separate tests that each check one link.
Do not collapse an entire page into a single test. Each distinct behavior — navigation, error states, conditional/role-gated UI, logout, i18n — is its own feature and belongs in its own test.
Decision rule: put assertions in the same test when they verify the same behavior under the same mock setup and navigation. Split into a new test when the behavior, mock setup, or user flow changes.
Use await test.step('description', async () => { ... }) for readability inside a feature test instead of
artificially splitting it.
// WRONG — one assertion per test creates redundant page loads
test('should show Documentation link', async ({tasklistIndexPage}) => {
await tasklistIndexPage.goto();
await tasklistIndexPage.header.openInfoSidebar();
await expect(tasklistIndexPage.header.documentationLink).toBeVisible();
});
test('should show Camunda Academy link', async ({tasklistIndexPage}) => {
await tasklistIndexPage.goto();
await tasklistIndexPage.header.openInfoSidebar();
test cases passed, vs 5 / 22 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.