add-test
Skill1 starsChanged 10 months agoMITView on GitHub
Add unit tests for component or function: $ARGUMENTS
- Installs packages
18 other projects use a version of this.
Adopted by
Most recently taken up by
- microsoft/veronatheir own version, first seen Nov 8, 2026
- TidalPaladin/skillstheir own version, first seen Nov 8, 2026
- flavien-ia/hypervibe-crafttheir own version, first seen Oct 25, 2026
- flavien-ia/hypervibe-harnesstheir own version, first seen Oct 23, 2026
- nativewind/react-native-csstheir own version, first seen Oct 9, 2026
- osmandapp/webtheir own version, first seen Oct 9, 2026
Used with
Projects with it also use review-pr, triage and 1 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
DockerSkillreview-pr
Review one or more incoming Docker documentation pull requests as a maintainer. Independently validate technical claims, assess editorial fit and information architecture, choose a verdict, and draft exact inline or PR-wide feedback behind a confirmation gate. Use for requests such as "review PR 123", "is this PR correct?", "does this information belong here?", "validate this PR", or "help review backlog PRs". Do not use to maintain or fix a PR you own; use maintain-pr for that.
Also in 3 projects that use this
Google CloudSkilltriage
Gather context on a change or bug and plan the implementation.
Also in 3 projects that use this
SentrySkillreview
Fixture review skill.
Also in 3 projects that use this
Other versions18 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 18
- gitkraken/vscode-gitlens★ 10ksame name
- nativewind/nativewind★ 8.1ksame name
- microsoft/verona★ 3.7ksame name
- The-OpenROAD-Project/OpenROAD★ 3.3ksame name
- OpenAEV-Platform/openaev★ 1.8ksame name
- DexForce/EmbodiChain★ 240same name
- fpindej/netrock★ 234same name
- nativewind/react-native-css★ 167same name
- osmandapp/web★ 63same name
- flavien-ia/hypervibe-craft★ 50same name
8 more not listed
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 repository5 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- add-featureSkill
- audit-and-fixSkill
- security-auditSkill
- validate-markdownSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
18 rules. 0 are common, 17 are distinctive, and 1 is very specific to this project.
0
Common
Most of the 17 edited versions we read keep these.
17
Distinctive
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 82
Before creating a new test file, check if one already exists:
- Distinctive: line 102
Read the source file to understand what needs testing:
- Distinctive: line 115
Use the Read tool to examine the source file and identify:
- Distinctive: line 124
Create a test file based on the file type:
- Distinctive: line 240
Add tests for each prop variation
- Distinctive: line 241
Test required vs optional props
- Distinctive: line 250
Test each event handler
- Distinctive: line 251
Test event handler with different inputs
- Distinctive: line 252
Test event handler error cases
- Distinctive: line 255
Test return values for various inputs
- Distinctive: line 256
Test edge cases (empty, null, undefined)
- Distinctive: line 257
Test boundary conditions (min, max)
- Distinctive: line 262
Write the customized test template to the test file using the Write tool.
- Very specific: line 265
Use data-testid attributes for stable selectors
- Distinctive: line 266
Follow existing test patterns from the project
- Distinctive: line 287
If tests fail, categorize and address the issues:
- Distinctive: line 312
Read error messages carefully
- Distinctive: line 320
Ensure tests meet quality standards:
“Common” is measured: kept by at least 6 in 10 of the 17 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Add Unit Tests: $ARGUMENTS
I'll create comprehensive unit tests for $ARGUMENTS following the project's testing patterns.
This will include:
- Identifying the source file (component or utility function)
- Creating a matching test file with proper naming convention
- Generating test cases with Jest and Testing Library
- Running tests to verify they pass
- Reporting results
Let's begin!
Process Steps
1. Identify the Source File
First, I'll locate the file to test.
For React components:
# Check components directory
if [ -f "expense-tracker-ai/components/$ARGUMENTS.tsx" ]; then
SOURCE_FILE="expense-tracker-ai/components/$ARGUMENTS.tsx"
TEST_FILE="expense-tracker-ai/components/$ARGUMENTS.test.tsx"
FILE_TYPE="component"
echo "✅ Found component: $SOURCE_FILE"
elif [ -f "expense-tracker-ai/components/$ARGUMENTS.ts" ]; then
SOURCE_FILE="expense-tracker-ai/components/$ARGUMENTS.ts"
TEST_FILE="expense-tracker-ai/components/$ARGUMENTS.test.ts"
FILE_TYPE="component"
echo "✅ Found component: $SOURCE_FILE"
fiFor utility functions:
# Check lib directory
if [ -f "expense-tracker-ai/lib/$ARGUMENTS.ts" ]; then
SOURCE_FILE="expense-tracker-ai/lib/$ARGUMENTS.ts"
TEST_FILE="expense-tracker-ai/lib/$ARGUMENTS.test.ts"
FILE_TYPE="utility"
echo "✅ Found utility: $SOURCE_FILE"
fiFor app pages:
# Check app directory
if [ -f "expense-tracker-ai/app/$ARGUMENTS.tsx" ]; then
SOURCE_FILE="expense-tracker-ai/app/$ARGUMENTS.tsx"
TEST_FILE="expense-tracker-ai/app/$ARGUMENTS.test.tsx"
FILE_TYPE="page"
echo "✅ Found page: $SOURCE_FILE"
fiIf file not found:
if [ -z "$SOURCE_FILE" ]; then
echo "❌ Error: Could not find $ARGUMENTS"
echo ""
echo "Available components:"
ls -1 expense-tracker-ai/components/*.tsx 2>/dev/null | sed 's/.*\///' | sed 's/\.tsx$//'
echo ""
echo "Available utilities:"
ls -1 expense-tracker-ai/lib/*.ts 2>/dev/null | sed 's/.*\///' | sed 's/\.ts$//'
exit 1
fi2. Check for Existing Tests
Before creating a new test file, check if one already exists:
if [ -f "$TEST_FILE" ]; then
echo "⚠️ Test file already exists: $TEST_FILE"
echo ""
echo "Options:"
echo "1. Update existing tests (add new test cases)"
echo "2. Replace existing tests (overwrite file)"
echo "3. Cancel (leave existing tests unchanged)"
echo ""
echo "What would you like to do?"
# Wait for user decision
else
echo "✅ No existing test file - will create new one"
fi3. Read and Analyze Source File
Read the source file to understand what needs testing:
# Read the source file to understand its structure
echo "Analyzing $SOURCE_FILE..."
# Look for key patterns:
# - Export statements (what's being exported)
# - Function definitions (what functions exist)
# - Props interfaces (what props are expected)
# - State hooks (what state is managed)Use the Read tool to examine the source file and identify:
- Exported components/functions
- Props interfaces
- State management
- Event handlers
- Key functionality to test
4. Generate Test Template
Create a test file based on the file type:
For React Components:
import { render, screen, fireEvent } from '@testing-library/react';
import { ComponentName } from './ComponentName';
describe('ComponentName', () => {
// Setup and teardown
beforeEach(() => {
// Clear any mocks or state before each test
});
afterEach(() => {
// Cleanup after each test
});
// Happy path tests
test('should render correctly', () => {
render(<ComponentName />);
expect(screen.getByTestId('component-name')).toBeInTheDocument();
});
test('should display expected content', () => {
render(<ComponentName />);
// Add specific content checks based on component
});
// Interaction tests
test('should handle user interaction', () => {
render(<ComponentName />);
const button = screen.getByRole('button', { name: /button text/i });
fireEvent.click(button);
// Assert expected behavior after interaction
});
// Props tests
test('should render with custom props', () => {
const mockProps = {
// Define test props
};
render(<ComponentName {...mockProps} />);
// Assert component renders correctly with props
});
// Edge cases
test('should handle empty state', () => {
render(<ComponentName />);
// Assert behavior with no data
});
test('should handle error state', () => {
// Test error scenarios
});
// Accessibility tests
test('should be accessible', () => {
const { container } = render(<ComponentName />);
// Basic accessibility checks
// Consider using @axe-core/react for comprehensive checks
});
});For Utility Functions:
import { functionName } from './fileName';
describe('functionName', () => {
// Happy path tests
test('should return expected output for valid input', () => {
const result = functionName(validInput);
expect(result).toBe(expectedOutput);
});
// Edge cases
test('should handle edge case: empty input', () => {
const result = functionName('');
expect(result).toBe(expectedEmptyOutput);
});
test('should handle edge case: null input', () => {
const result = functionName(null);
expect(result).toBe(expectedNullOutput);
});
test('should handle edge case: undefined input', () => {
const result = functionName(undefined);
expect(result).toBe(expectedUndefinedOutput);
});
// Boundary conditions
test('should handle minimum value', () => {
const result = functionName(minValue);
expect(result).toBe(expectedMinOutput);
});
test('should handle maximum value', () => {
const result = functionName(maxValue);
expect(result).toBe(expectedMaxOutput);
});
// Error handling
test('should throw error for invalid input', () => {
expect(() => functionName(invalidInput)).toThrow();
});
});5. Customize Tests Based on Source Analysis
Based on the source file analysis, customize the test template:
For components with props:
- Add tests for each prop variation
- Test required vs optional props
- Test prop validation
For components with state:
- Test initial state
- Test state changes
- Test state-dependent rendering
For components with events:
- Test each event handler
- Test event handler with different inputs
- Test event handler error cases
For utility functions:
- Test return values for various inputs
- Test edge cases (empty, null, undefined)
- Test boundary conditions (min, max)
- Test error handling
6. Create the Test File
Write the customized test template to the test file using the Write tool.
Important conventions:
- Use
data-testidattributes for stable selectors - Follow existing test patterns from the project
- Include descriptive test names
- Group related tests with
describeblocks - Cover happy path, edge cases, and error states
7. Run the Tests
Execute the test suite to verify the tests work:
cd expense-tracker-ai
# Run just the new test file
npm test -- $ARGUMENTS.test
# If tests fail, run in watch mode for debugging
npm run test:watch -- $ARGUMENTS.test8. Handle Test Failures
If tests fail, categorize and address the issues:
Type 1: Test Implementation Issues
- Incorrect selectors → Update test selectors
- Wrong assertions → Fix test expectations
- Missing mocks → Add required mocks
# Debug in watch mode
npm run test:watch -- $ARGUMENTS.test
# Run with verbose output
npm test -- --verbose $ARGUMENTS.testType 2: Missing Test Infrastructure
- Missing
data-testidin component → Add to source file - Missing test setup → Update jest.setup.js
- Missing mocks → Create mock files
Type 3: Source Code Issues
- Bugs revealed by tests → Fix source code
- Type errors → Fix TypeScript issues
Resolution approach:
- Read error messages carefully
- Identify the root cause (test vs source)
- Fix the appropriate file
- Re-run tests
- Iterate until all tests pass
9. Validate Test Quality
Ensure tests meet quality standards:
Coverage checklist:
- ✅ Happy path scenarios tested
- ✅ Edge cases covered (empty, null, boundary conditions)
- ✅ Error states tested
- ✅ User interactions tested (for components)
- ✅ Props variations tested (for components)
- ✅ Return values tested (for functions)
Quality checklist:
- ✅ Tests are independent (can run in any order)
- ✅ Tests are deterministic (same result every time)
- ✅ Tests use stable selectors (
data-testid, not CSS classes) - ✅ Tests have descriptive names
- ✅ Tests follow project conventions
- ✅ No console errors or warnings
10. Report Results
Generate a summary of what was created:
✅ Unit Tests Created Successfully
📊 Summary:
- Source file: $SOURCE_FILE
- Test file: $TEST_FILE
- File type: $FILE_TYPE
- Test cases: [count]
- All tests passing: ✓
📝 Test Coverage:
- Happy path scenarios ([count] tests)
- Edge cases ([count] tests)
- Error handling ([count] tests)
- User interactions ([count] tests - for components)
- Props variations ([count] tests - for components)
✅ Test Quality:
- Independent tests: ✓
- Stable selectors: ✓
- Descriptive names: ✓
- Project conventions: ✓
💡 Next Steps:
- Run full test suite: npm test
- Check coverage: npm test -- --coverage
- Run in watch mode: npm run test:watchExample Usage
Testing a Component
# Add tests for ExpenseForm component
add-test ExpenseFormExpected output:
✅ Found component: expense-tracker-ai/components/ExpenseForm.tsx
✅ No existing test file - will create new one
Analyzing expense-tracker-ai/components/ExpenseForm.tsx...
Creating test file with coverage for:
- Form rendering
- Input validation
- Form submission
- Error states
- Props handling
✅ Unit Tests Created Successfully
📊 Summary:
- Source file: expense-tracker-ai/components/ExpenseForm.tsx
- Test file: expense-tracker-ai/components/ExpenseForm.test.tsx
- File type: component
- Test cases: 12
- All tests passing: ✓Testing a Utility Function
# Add tests for getCategoryColor utility
add-test getCategoryColorExpected output:
✅ Found utility: expense-tracker-ai/lib/utils.ts
Analyzing getCategoryColor function...
Creating test file with coverage for:
- Valid category names
- Hash consistency
- Edge cases (empty, null)
- Return value format
✅ Unit Tests Created Successfully
📊 Summary:
- Source file: expense-tracker-ai/lib/utils.ts
- Test file: expense-tracker-ai/lib/utils.test.ts
- File type: utility
- Test cases: 8
- All tests passing: ✓Project-Specific Patterns
This skill follows the expense tracker app's testing conventions:
Test Setup Patterns
From jest.setup.js:
// ResizeObserver mock for Recharts components
global.ResizeObserver = class ResizeObserver {
observe() {}
unobserve() {}
disconnect() {}
};Common Test Patterns
localStorage mocking:
beforeEach(() => {
const localStorageMock = {
getItem: jest.fn(),
setItem: jest.fn(),
clear: jest.fn(),
};
global.localStorage = localStorageMock as any;
});Testing Library selectors:
// Prefer data-testid
screen.getByTestId('submit-button')
// Use semantic queries
screen.getByRole('button', { name: /submit/i })
// Avoid brittle selectors
// ❌ screen.getByClassName('btn-primary')
// ❌ container.querySelector('.form button:nth-child(2)')Async testing:
test('should load data asynchronously', async () => {
render(<Component />);
// Wait for element to appear
const element = await screen.findByTestId('loaded-data');
expect(element).toBeInTheDocument();
});Troubleshooting
Tests Fail: Module Not Found
Error: Cannot find module '@testing-library/react'
Solution:
cd expense-tracker-ai
npm install --save-dev @testing-library/react @testing-library/jest-domTests Fail: ResizeObserver Not Defined
Error: ReferenceError: ResizeObserver is not defined
Solution: Already handled in jest.setup.js. If error persists:
# Verify jest.setup.js is configured in jest.config.js
cat jest.config.js | grep setupFilesAfterEnvTests Fail: Type Errors
Error: Type error: Cannot find name 'describe'
Solution:
# Install Jest types
npm install --save-dev @types/jest
# Verify tsconfig.json includes jest types
cat tsconfig.json | grep jestTests Pass But Don't Actually Test Anything
Symptom: Tests pass but don't catch obvious bugs
Solution: Review assertions:
// ❌ Weak test (always passes)
test('should work', () => {
const result = someFunction();
expect(result).toBeDefined();
});
// ✅ Strong test (validates actual behavior)
test('should return correct calculation', () => {
const result = calculateTotal([10, 20, 30]);
expect(result).toBe(60);
});Related Documentation
- Testing Guide: expense-tracker-ai/docs/dev/testing-guide.md
- Jest Configuration: expense-tracker-ai/jest.config.js
- Example Tests: expense-tracker-ai/components/MonthlyInsights.test.tsx
- Testing Library Docs: https://testing-library.com/docs/react-testing-library/intro/
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.

