frontend-test
Skill355 starsChanged 13 months agoMITView on GitHub
Generate frontend component tests (React Testing Library, Vue Test Utils, snapshot) for existing components. Auto-invoke when user says "test this component", "write component test", or "add component test".
3 other projects use a version of this.
Adopted by
Most recently taken up by
- huoshen80/ReinaManagertheir own version, first seen Oct 8, 2026
- rainmancswh-dot/claude-skillstheir own version, first seen Jun 16, 2026
- alekspetrov/navigatorword for word, first seen Oct 31, 2025
Other versions3 projects use a version of this.
Word for word · 1
- alekspetrov/navigator★ 355100% same
Edited · 0
None found.
Wrote their own version · 2
- huoshen80/ReinaManager★ 737same name
- rainmancswh-dot/claude-skills★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository32 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- templates/CLAUDE.mdCLAUDE.md
- backend-endpointSkill
- backend-testSkill
- database-migrationSkill
- frontend-componentSkill
- nav-briefSkill
- nav-compactSkill
- nav-deep-researchSkill
- nav-diagnoseSkill
- nav-featuresSkill
- nav-graphSkill
- nav-initSkill
- nav-loopSkill
- nav-markerSkill
- nav-onboardSkill
- nav-pilotSkill
- nav-profileSkill
- nav-releaseSkill
- nav-simplifySkill
- nav-skill-creatorSkill
- nav-sopSkill
- nav-startSkill
- nav-statsSkill
- nav-sync-claudeSkill
- nav-taskSkill
- nav-trizSkill
- nav-upgradeSkill
- nav-workflowSkill
- plugin-slash-commandSkill
- product-designSkill
- visual-regressionSkill
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 5 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 39
Look for patterns about test utilities used (RTL vs Enzyme), snapshot policy, accessibility-test conventions.
- Distinctive: line 43
Ask if not specified:
- Distinctive: line 50
Read the component in full so generated tests cover actual behavior (props handled, events emitted, conditional rendering, etc.).
- Very specific: line 64
Check for setupTests.ts / vitest.setup.ts to understand global utilities and matchers.
- Distinctive: line 109
Snapshot tests: only generate if the project's existing tests use them (check peer test files first).
- Distinctive: line 117
If tests fail because they assume incorrect behavior, fix the tests.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Frontend Component Test Generator
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.
When to Invoke
Auto-invoke when user says:
- "Test this component"
- "Write component test"
- "Add component test"
- "Test component [name]"
- "Component tests for [name]"
Execution Steps
Step 0: Check Existing Patterns (Phase 0)
PLUGIN_DIR="${CLAUDE_PLUGIN_ROOT:-$(cat "${NAVIGATOR_CONFIG_HOME:-${XDG_CONFIG_HOME:-$HOME/.config}/navigator}/plugin-root" 2>/dev/null)}"
[ -d "$PLUGIN_DIR/skills" ] || PLUGIN_DIR="$HOME/.claude/plugins/marketplaces/navigator-marketplace"
python3 "$PLUGIN_DIR/skills/nav-graph/functions/graph_manager.py" \
--action query --concept frontend \
--graph-path .agent/knowledge/graph.json 2>/dev/null | head -40
python3 "$PLUGIN_DIR/skills/nav-graph/functions/graph_manager.py" \
--action query --concept testing \
--graph-path .agent/knowledge/graph.json 2>/dev/null | head -40Look for patterns about test utilities used (RTL vs Enzyme), snapshot policy, accessibility-test conventions.
Step 1: Locate Component Under Test
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.).
Step 2: Detect Test Framework + Library
# 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.
Step 3: Generate Test File
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.
Step 4: Verify
{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.
Step 5: Emit Execution Summary (Graph Ingestion)
{
"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:
PLUGIN_DIR="${CLAUDE_PLUGIN_ROOT:-$(cat "${NAVIGATOR_CONFIG_HOME:-${XDG_CONFIG_HOME:-$HOME/.config}/navigator}/plugin-root" 2>/dev/null)}"
[ -d "$PLUGIN_DIR/skills" ] || PLUGIN_DIR="$HOME/.claude/plugins/marketplaces/navigator-marketplace"
echo '<execution_summary JSON>' | python3 "$PLUGIN_DIR/skills/nav-graph/functions/execution_to_graph.py" -Success Criteria
- Test file colocated with component (or per project convention)
- Rendering, interactions, and at least one accessibility check covered
- Queries use
getByRole/getByLabelTextovergetByTestIdwhere possible - All generated tests pass on first run
- Execution summary emitted
When NOT to Use This Skill
- You're creating a new component from scratch — use
frontend-component(it generates tests as part of its workflow) - You want to test a backend endpoint or service — use
backend-test - You want visual regression testing — use
visual-regression
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

