Generates test plans, writes unit/integration/E2E test files, identifies coverage gaps, and flags common testing anti-patterns. Use when writing tests, creating test suites, planning test strategies, mocking dependencies, measuring code coverage, or test planning.
100
100%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
| Rule | Detail |
|---|---|
| One suite per session | Never run all suites in one conversation |
| Max 3 screenshots | Per session |
evaluate_script() over take_snapshot() | Returns less data |
| Reload between flows | Clears state |
| Log results | Append to .opencastle/logs/e2e-results.md |
Suite files: see .opencastle/project.instructions.md.
| Category | What to cover |
|---|---|
| Initial state | Page loads with defaults; components in expected state |
| User interactions | Buttons, dropdowns, filters (URL params + refetch), form validation |
| State transitions | Filter changes produce different results; loading states; backend sync |
| Edge cases | Empty results, min/max boundaries, invalid input, network errors |
| Integration | Data flow server→UI, URL params↔state, server vs client filtering |
| Responsive (MANDATORY for UI) | All breakpoints per browser-testing skill / validation-gates Gate 3 |
| Layer | Minimum |
|---|---|
| Unit (functions, components, hooks) | 95% |
| Integration (boundaries, URL sync) | All boundaries |
| E2E (journeys, interactions, errors) | All critical paths |
| Anti-Pattern | Correct Approach |
|---|---|
| Testing only initial page load | Test filter changes and different results |
| Assuming filters work because they render | Verify each option changes results |
| Client-side only | Verify server requests are triggered |
| Single scenario | Test urban, rural, edge, out-of-range |
| Visual inspection only | Verify data values programmatically |
# Unit / integration
npx vitest run --coverage # all tests + coverage
npx vitest run src/utils.test.ts # single file
# E2E (Playwright)
npx playwright test # all E2E suites
npx playwright test --ui # interactive mode// Unit test with mock
import { describe, it, expect, vi } from 'vitest';
import { fetchItems } from './api';
describe('fetchItems', () => {
it('returns filtered results', async () => {
vi.spyOn(global, 'fetch').mockResolvedValue(
new Response(JSON.stringify([{ id: 1, name: 'test' }]))
);
const items = await fetchItems({ category: 'active' });
expect(items).toHaveLength(1);
expect(fetch).toHaveBeenCalledWith(expect.stringContaining('category=active'));
});
});// E2E test (Playwright)
import { test, expect } from '@playwright/test';
test('filter updates results and URL', async ({ page }) => {
await page.goto('/items');
await page.getByRole('combobox', { name: 'Category' }).selectOption('active');
await expect(page).toHaveURL(/category=active/);
await expect(page.getByRole('listitem')).not.toHaveCount(0);
});| Resource | Purpose |
|---|---|
| browser-testing skill | Chrome DevTools automation for E2E |
| validation-gates Gate 3 | Responsive breakpoint checks |
project.instructions.md | Suite files, project-specific test config |
f5c8508
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.