langgenius
Generate Vitest + React Testing Library tests for Dify frontend components, hooks, and utilities. Triggers on testing, spec files, coverage, Vitest, RTL, unit tests, integration tests, or write/review test requests.
bunx add-skill langgenius/dify -s frontend-testingLoadingβ¦
This skill enables Claude to generate high-quality, comprehensive frontend tests for the Dify project following established conventions and best practices.
β οΈ Authoritative Source: This skill is derived from
web/docs/test.md. Use Vitest mock/timer APIs (vi.*).
Apply this skill when the user:
pnpm analyze-component output as contextDo NOT apply when:
| Tool | Version | Purpose |
|---|---|---|
| Vitest | 4.0.16 | Test runner |
| React Testing Library | 16.0 | Component testing |
| jsdom | - | Test environment |
| nock | 14.0 | HTTP mocking |
| TypeScript | 5.x | Type safety |
# Run all tests
pnpm test
# Watch mode
pnpm test:watch
# Run specific file
pnpm test path/to/file.spec.tsx
# Generate coverage report
pnpm test:coverage
# Analyze component complexity
pnpm analyze-component <path>
# Review existing test
pnpm analyze-component <path> --review
ComponentName.spec.tsx (same directory as component)web/__tests__/ directoryimport { render, screen, fireEvent, waitFor } from '@testing-library/react'
import Component from './index'
// β
Import real project components (DO NOT mock these)
// import Loading from '@/app/components/base/loading'
// import { ChildComponent } from './child-component'
// β
Mock external dependencies only
vi.mock('@/service/api')
vi.mock('next/navigation', () => ({
useRouter: () => ({ push: vi.fn() }),
usePathname: () => '/test',
}))
// β
Zustand stores: Use real stores (auto-mocked globally)
// Set test state with: useAppStore.setState({ ... })
// Shared state for mocks (if needed)
let mockSharedState = false
describe('ComponentName', () => {
beforeEach(() => {
vi.clearAllMocks() // β
Reset mocks BEFORE each test
mockSharedState = false // β
Reset shared state
})
// Rendering tests (REQUIRED)
describe('Rendering', () => {
it('should render without crashing', () => {
// Arrange
const props = { title: 'Test' }
// Act
render(<Component {...props} />)
// Assert
expect(screen.getByText('Test')).toBeInTheDocument()
})
})
// Props tests (REQUIRED)
describe('Props', () => {
it('should apply custom className', () => {
render(<Component className="custom" />)
expect(screen.getByRole('button')).toHaveClass('custom')
})
})
// User Interactions
describe('User Interactions', () => {
it('should handle click events', () => {
const handleClick = vi.fn()
render(<Component onClick={handleClick} />)
fireEvent.click(screen.getByRole('button'))
expect(handleClick).toHaveBeenCalledTimes(1)
})
})
// Edge Cases (REQUIRED)
describe('Edge Cases', () => {
it('should handle null data', () => {
render(<Component data={null} />)
expect(screen.getByText(/no data/i)).toBeInTheDocument()
})
it('should handle empty array', () => {
render(<Component items={[]} />)
expect(screen.getByText(/empty/i)).toBeInTheDocument()
})
})
})
NEVER generate all test files at once. For complex components or multi-file directories:
For each file:
ββββββββββββββββββββββββββββββββββββββββββ
β 1. Write test β
β 2. Run: pnpm test <file>.spec.tsx β
β 3. PASS? β Mark complete, next file β
β FAIL? β Fix first, then continue β
ββββββββββββββββββββββββββββββββββββββββββ
Process in this order for multi-file testing:
π See
references/workflow.mdfor complete workflow details and todo list format.
When assigned to test a directory/path, test ALL content within that path:
index file)Prefer integration testing when writing tests for a directory:
@/service/*), next/navigation, complex context providers@/app/components/base/*)See Test Structure Template for correct import/mock patterns.
Every test should clearly separate:
// β Avoid: hardcoded text assertions
expect(screen.getByText('Loading...')).toBeInTheDocument()
// β
Better: role-based queries
expect(screen.getByRole('status')).toBeInTheDocument()
// β
Better: pattern matching
expect(screen.getByText(/loading/i)).toBeInTheDocument()
Each test verifies ONE user-observable behavior:
// β
Good: One behavior
it('should disable button when loading', () => {
render(<Button loading />)
expect(screen.getByRole('button')).toBeDisabled()
})
// β Bad: Multiple behaviors
it('should handle loading state', () => {
render(<Button loading />)
expect(screen.getByRole('button')).toBeDisabled()
expect(screen.getByText('Loading...')).toBeInTheDocument()
expect(screen.getByRole('button')).toHaveClass('loading')
})
Use should <behavior> when <condition>:
it('should show error message when validation fails')
it('should call onSubmit when form is valid')
it('should disable input when isReadOnly is true')
| Feature | Test Focus |
|---|---|
useState | Initial state, transitions, cleanup |
useEffect | Execution, dependencies, cleanup |
| Event handlers | All onClick, onChange, onSubmit, keyboard |
| API calls | Loading, success, error states |
| Routing | Navigation, params, query strings |
useCallback/useMemo | Referential equality |
| Context | Provider values, consumer behavior |
| Forms | Validation, submission, error display |
For each test file generated, aim for:
Note: For multi-file directories, process one file at a time with full coverage each. See
references/workflow.md.
For more detailed information, refer to:
references/workflow.md - Incremental testing workflow (MUST READ for multi-file testing)references/mocking.md - Mock patterns, Zustand store testing, and best practicesreferences/async-testing.md - Async operations and API callsreferences/domain-components.md - Workflow, Dataset, Configuration testingreferences/common-patterns.md - Frequently used testing patternsreferences/checklist.md - Test generation checklist and validation stepsweb/docs/test.md - The canonical testing specification. This skill is derived from this document.web/utils/classnames.spec.ts - Utility function testsweb/app/components/base/button/index.spec.tsx - Component testsweb/__mocks__/provider-context.ts - Mock factory exampleweb/vitest.config.ts - Vitest configurationweb/vitest.setup.ts - Test environment setupweb/scripts/analyze-component.js - Component analysis toolweb/vitest.setup.ts (for example react-i18next, next/image); mock other modules like ky or mime locally in test files.Trigger when the user requests a review of frontend files (e.g., `.tsx`, `.ts`, `.js`). Support both pending-change reviews and focused file reviews while applying the checklist rules.
Refactor high-complexity React components in Dify frontend. Use when `pnpm analyze-component --json` shows complexity > 50 or lineCount > 300, when the user asks for code splitting, hook extraction, or complexity reduction, or when `pnpm analyze-component` warns to refactor before testing; avoid for simple/well-structured components, third-party wrappers, or when the user explicitly wants testing without refactoring.
Review UI code for Web Interface Guidelines compliance. Use when asked to "review my UI", "check accessibility", "audit design", "review UX", or "check my site against best practices".
Guide for creating effective skills. This skill should be used when users want to create a new skill (or update an existing skill) that extends Claude's capabilities with specialized knowledge, workflows, or tool integrations.