Help us improve
Share bugs, ideas, or general feedback.
From navigator
Generates frontend component tests (React Testing Library, Vue Test Utils, snapshot) for existing components. Useful when adding or expanding test coverage.
npx claudepluginhub alekspetrov/navigator --plugin navigatorHow this skill is triggered — by the user, by Claude, or both
Slash command
/navigator:frontend-testThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Generate component tests for **existing components** — typically components written without tests, or where additional coverage is needed beyond what `frontend-component` already produced.
Guides frontend unit, component, and light integration tests using React Testing Library, Vue Test Utils, accessible queries, user-event, mocks, and state coverage.
Provides testing patterns and examples for React components, hooks, and integrations using Vitest, React Testing Library, and Jest.
Guides framework-agnostic testing of front-end UIs with DOM Testing Library: behavior-first queries, userEvent interactions, async patterns, MSW mocking, and anti-patterns.
Share bugs, ideas, or general feedback.
Generate component tests for existing components — typically components written without tests, or where additional coverage is needed beyond what frontend-component already produced.
When to use this vs.
frontend-component:frontend-componentgenerates tests as part of creating a new component. Usefrontend-testwhen the component already exists and you need to add or expand its tests.
Auto-invoke when user says:
python3 skills/nav-graph/functions/graph_manager.py \
--action query --concept frontend \
--graph-path .agent/knowledge/graph.json 2>/dev/null | head -40
python3 skills/nav-graph/functions/graph_manager.py \
--action query --concept testing \
--graph-path .agent/knowledge/graph.json 2>/dev/null | head -40
Look for patterns about test utilities used (RTL vs Enzyme), snapshot policy, accessibility-test conventions.
Ask if not specified:
Which component should I test?
- File path (e.g., src/components/UserProfile.tsx)
- Component name (e.g., UserProfile)
Read the component in full so generated tests cover actual behavior (props handled, events emitted, conditional rendering, etc.).
# React Testing Library
grep -q '"@testing-library/react"' package.json 2>/dev/null && echo "RTL detected"
# Vue Test Utils
grep -q '"@vue/test-utils"' package.json 2>/dev/null && echo "Vue Test Utils detected"
# Test runner
grep -q '"vitest"' package.json 2>/dev/null && echo "Vitest"
grep -q '"jest"' package.json 2>/dev/null && echo "Jest"
Check for setupTests.ts / vitest.setup.ts to understand global utilities and matchers.
File location: colocate with the component (UserProfile.test.tsx next to UserProfile.tsx) unless the project convention is otherwise.
Structure (RTL + Vitest/Jest):
import { describe, it, expect, vi } from 'vitest'; // or '@jest/globals'
import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import { {COMPONENT_NAME} } from './{COMPONENT_NAME}';
describe('{COMPONENT_NAME}', () => {
describe('rendering', () => {
it('renders with required props', () => {
render(<{COMPONENT_NAME} {...{REQUIRED_PROPS}} />);
expect(screen.getByRole('{ROLE}')).toBeInTheDocument();
});
it('renders conditional content when prop is set', () => {
render(<{COMPONENT_NAME} {...{REQUIRED_PROPS}} {OPTIONAL_PROP} />);
expect(screen.getByText('{EXPECTED_TEXT}')).toBeInTheDocument();
});
});
describe('interactions', () => {
it('calls onClick handler when clicked', async () => {
const user = userEvent.setup();
const onClick = vi.fn();
render(<{COMPONENT_NAME} {...{REQUIRED_PROPS}} onClick={onClick} />);
await user.click(screen.getByRole('button'));
expect(onClick).toHaveBeenCalledOnce();
});
});
describe('accessibility', () => {
it('has accessible name', () => {
render(<{COMPONENT_NAME} {...{REQUIRED_PROPS}} />);
expect(screen.getByRole('{ROLE}')).toHaveAccessibleName();
});
});
});
Snapshot tests: only generate if the project's existing tests use them (check peer test files first). They're easy to over-rely on; prefer assertion-based tests for behavior, snapshots only for stable visual structure.
{TEST_COMMAND} {COMPONENT_NAME}
If tests fail because they assume incorrect behavior, fix the tests. Only fix the component if it's actually buggy — surface that to the user.
{
"execution_summary": {
"skill": "frontend-test",
"task": "tests for {COMPONENT_NAME}",
"files_created": ["{test file path}"],
"files_modified": [],
"tests_added": ["{test file path}"],
"stack_detected": "{e.g. react+rtl+vitest}",
"patterns_followed": [
{"summary": "{e.g. queries via getByRole, not getByTestId}", "concepts": ["frontend", "testing"], "confidence": 0.85}
],
"decisions_made": [
{"summary": "{e.g. asserted accessible name instead of snapshot to avoid brittleness}", "concepts": ["testing"], "confidence": 0.8}
],
"pitfalls_avoided": [
{"summary": "{e.g. used userEvent.setup() not fireEvent — RTL recommendation}", "concepts": ["testing"], "confidence": 0.85}
],
"assumptions_made": ["{e.g. project uses Vitest globals from setup file}"]
}
}
Ingest:
echo '<execution_summary JSON>' | python3 skills/nav-graph/functions/execution_to_graph.py -
getByRole / getByLabelText over getByTestId where possiblefrontend-component (it generates tests as part of its workflow)backend-testvisual-regression