Agent skill

Frontend Testing

by Ohh-889 in Ohh-889/skyroc

Generate Vitest + React Testing Library tests for Dify frontend components, hooks, and utilities.

MITAuto-check passedTesting & QA

Install Frontend Testing

skills CLI
$ npx skills add Ohh-889/skyroc --skill frontend-testing -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install Ohh-889/skyroc frontend-testing --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/Ohh-889/skyroc.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/frontend-testing .claude/skills/frontend-testing && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
frontend-testing
GitHub stars
795
Used in
1 other repo
Token cost
~2.5k tokens
SKILL.md length
716 words
Files
10 (incl. references, assets)
Skills in repo
18
Repo updated
First seen
Licence
MIT

At a glance

Generate Vitest + React Testing Library tests for Dify frontend components, hooks, and utilities.

  • Works in 4 steps: AAA Pattern (Arrange-Act-Assert) → Black-Box Testing → Single Behavior Per Test → …
  • Integration tests
  • SKILL.md covers When to Apply This Skill, Quick Reference, Test Structure Template and Testing Workflow (CRITICAL), plus 6 more sections
  • Runs TypeScript scripts from its folder; calls pnpm

What it does

Frontend Testing is an agent skill from Ohh-889/skyroc. 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.

Its SKILL.md is about 2.5k tokens, which your agent loads only when the skill is triggered. The skill folder holds 11 other files, including reference files and assets (for example `assets/hook-test.template.ts`, `assets/utility-test.template.ts` and `references/async-testing.md`).

It sits in Testing & QA, covering Unit testing and Integration testing. It works with Dify, Vitest and Testing Library. The repository describes itself as: Skyroc 是一个基于 React 19 + TypeScript 的跨端前端工程化 monorepo:既提供开箱即用的 Web 中后台模板(Admin / RuoYi 对接版)和 Expo 移动端业务模板,也把请求、状态、日志、主题、双端 UI 组件库等能力沉淀为边界清晰的 workspace 包。 The licence is MIT.

When your agent uses it

  • Integration tests
  • Write/review test requests

Example prompts

  • “/frontend-testing”

Requirements

  • Node.js

Workflow steps

4 steps, taken from the step headings in SKILL.md.

  1. AAA Pattern (Arrange-Act-Assert)
  2. Black-Box Testing
  3. Single Behavior Per Test
  4. Semantic Naming

What it can do on your machine

Read from SKILL.md and the folder at commit 10ddd27. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Ships script files (TypeScript), which the agent can run.

    Shell commands in SKILL.md call:

    • pnpm

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use pnpm, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Frontend Testing loads about 2.5k tokens when it runs, and up to ~18k if it reads all its reference files. Until then it costs about 58 tokens; SKILL.md has 716 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~58
When it runs · the whole SKILL.md, loaded when a task matches
~2.5k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~18k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from Ohh-889/skyroc at commit 10ddd27, republished under its MIT licence (© Ohh-889). 716 words, ~2,532 tokens.

Download SKILL.mdSave it as .claude/skills/frontend-testing/SKILL.md (or your agent's skills folder). This skill also uses 9 other files; get the full folder from GitHub.
name
frontend-testing
description
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.

Dify Frontend Testing Skill

This skill enables Codex 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/testing/testing.md. Use Vitest mock/timer APIs (vi.*).

When to Apply This Skill

Apply this skill when the user:

  • Asks to write tests for a component, hook, or utility
  • Asks to review existing tests for completeness
  • Mentions Vitest, React Testing Library, RTL, or spec files
  • Requests test coverage improvement
  • Uses pnpm analyze-component output as context
  • Mentions testing, unit tests, or integration tests for frontend code
  • Wants to understand testing patterns in the Dify codebase

Do NOT apply when:

  • User is asking about backend/API tests (Python/pytest)
  • User is asking about E2E tests (Playwright/Cypress)
  • User is only asking conceptual questions without code context

Quick Reference

Tech Stack
ToolVersionPurpose
Vitest4.0.16Test runner
React Testing Library16.0Component testing
jsdom-Test environment
nock14.0HTTP mocking
TypeScript5.xType safety
Key Commands
bash
# 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
File Naming
  • Test files: ComponentName.spec.tsx (same directory as component)
  • Integration tests: web/__tests__/ directory

Test Structure Template

typescript
import { 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()
    })
  })
})

Testing Workflow (CRITICAL)

⚠️ Incremental Approach Required

NEVER generate all test files at once. For complex components or multi-file directories:

  1. Analyze & Plan: List all files, order by complexity (simple → complex)
  2. Process ONE at a time: Write test → Run test → Fix if needed → Next
  3. Verify before proceeding: Do NOT continue to next file until current passes
For each file:
  ┌────────────────────────────────────────┐
  │ 1. Write test                          │
  │ 2. Run: pnpm test <file>.spec.tsx      │
  │ 3. PASS? → Mark complete, next file    │
  │    FAIL? → Fix first, then continue    │
  └────────────────────────────────────────┘
Complexity-Based Order

Process in this order for multi-file testing:

  1. 🟢 Utility functions (simplest)
  2. 🟢 Custom hooks
  3. 🟡 Simple components (presentational)
  4. 🟡 Medium components (state, effects)
  5. 🔴 Complex components (API, routing)
  6. 🔴 Integration tests (index files - last)
When to Refactor First
  • Complexity > 50: Break into smaller pieces before testing
  • 500+ lines: Consider splitting before testing
  • Many dependencies: Extract logic into hooks first

📖 See references/workflow.md for complete workflow details and todo list format.

Testing Strategy

Path-Level Testing (Directory Testing)

When assigned to test a directory/path, test ALL content within that path:

  • Test all components, hooks, utilities in the directory (not just index file)
  • Use incremental approach: one file at a time, verify each before proceeding
  • Goal: 100% coverage of ALL files in the directory
Integration Testing First

Prefer integration testing when writing tests for a directory:

  • ✅ Import real project components directly (including base components and siblings)
  • ✅ Only mock: API services (@/service/*), next/navigation, complex context providers
  • ❌ DO NOT mock base components (@/app/components/base/*)
  • ❌ DO NOT mock sibling/child components in the same directory

See Test Structure Template for correct import/mock patterns.

Core Principles

1. AAA Pattern (Arrange-Act-Assert)

Every test should clearly separate:

  • Arrange: Setup test data and render component
  • Act: Perform user actions
  • Assert: Verify expected outcomes
Show full SKILL.md (281 more words)Show less
2. Black-Box Testing
  • Test observable behavior, not implementation details
  • Use semantic queries (getByRole, getByLabelText)
  • Avoid testing internal state directly
  • Prefer pattern matching over hardcoded strings in assertions:
typescript
// ❌ 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()
3. Single Behavior Per Test

Each test verifies ONE user-observable behavior:

typescript
// ✅ 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')
})
4. Semantic Naming

Use should <behavior> when <condition>:

typescript
it('should show error message when validation fails')
it('should call onSubmit when form is valid')
it('should disable input when isReadOnly is true')

Required Test Scenarios

Always Required (All Components)
  1. Rendering: Component renders without crashing
  2. Props: Required props, optional props, default values
  3. Edge Cases: null, undefined, empty values, boundary conditions
Conditional (When Present)
FeatureTest Focus
useStateInitial state, transitions, cleanup
useEffectExecution, dependencies, cleanup
Event handlersAll onClick, onChange, onSubmit, keyboard
API callsLoading, success, error states
RoutingNavigation, params, query strings
useCallback/useMemoReferential equality
ContextProvider values, consumer behavior
FormsValidation, submission, error display

Coverage Goals (Per File)

For each test file generated, aim for:

  • ✅ 100% function coverage
  • ✅ 100% statement coverage
  • ✅ >95% branch coverage
  • ✅ >95% line coverage

Note: For multi-file directories, process one file at a time with full coverage each. See references/workflow.md.

Detailed Guides

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 practices
  • references/async-testing.md - Async operations and API calls
  • references/domain-components.md - Workflow, Dataset, Configuration testing
  • references/common-patterns.md - Frequently used testing patterns
  • references/checklist.md - Test generation checklist and validation steps

Authoritative References

Primary Specification (MUST follow)
  • web/testing/testing.md - The canonical testing specification. This skill is derived from this document.
Reference Examples in Codebase
  • web/utils/classnames.spec.ts - Utility function tests
  • web/app/components/base/button/index.spec.tsx - Component tests
  • web/__mocks__/provider-context.ts - Mock factory example
Project Configuration
  • web/vitest.config.ts - Vitest configuration
  • web/vitest.setup.ts - Test environment setup
  • web/scripts/analyze-component.js - Component analysis tool
  • Modules are not mocked automatically. Global mocks live in web/vitest.setup.ts (for example react-i18next, next/image); mock other modules like ky or mime locally in test files.

© Ohh-889, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 9 other files (references, assets) in .agents/skills/frontend-testing of Ohh-889/skyroc.

  • SKILL.md
  • assets/component-test.template.tsx
  • assets/hook-test.template.ts
  • assets/utility-test.template.ts
  • references/async-testing.md
  • references/checklist.md
  • references/common-patterns.md
  • references/domain-components.md
  • references/mocking.md
  • references/workflow.md

Open the folder on GitHubat commit 10ddd27

Used in 1 other repository

We found 2 copies of this SKILL.md (exact, near-identical or edited) in other folders, from 1 other GitHub owner. This page covers the copy in Ohh-889/skyroc, which our catalogue first saw on October 7, 2026.

Compare with similar skills

Frontend Testing next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Frontend Testing compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Frontend Testing this skillOhh-889/skyroc7951 repos~2.5kAutomated safety check: PassMIT
Hilla TestAI-Unified-Process/marketplace141—~3.9kAutomated safety check: WarnApache-2.0
Dify Frontend Testinglanggenius/dify158k—~242Automated safety check: PassCustom licence
Test Writing WorkflowiOfficeAI/AionUi33k1 repos~1.2kAutomated safety check: PassApache-2.0
Designing TestsCloudAI-X/claude-workflow-v21.4k1 repos~1.5kAutomated safety check: PassMIT
Write Testsgrafana/synthetic-monitoring-app171—~1.2kAutomated safety check: PassAGPL-3.0

Similar skills

  • Hilla Test

    AI-Unified-Process/marketplace

    Creates tests for Hilla use cases on both sides of the browser boundary: Vitest + React Testing Library tests for the React/TypeScript view (with the generated endpoint clients mocked) and Spring…

    141 GitHub stars~3.9k tokensUpdated 3 days ago
    Testing & QAAuto-check: warnings
  • Dify Frontend Testing

    langgenius/dify

    Use when writing or changing Vitest or React Testing Library tests under `web/` or `packages/dify-ui/`, or when the user explicitly requests frontend test…

    158k GitHub stars~242 tokensUpdated today
    Testing & QAAuto-check passed
  • Test Writing Workflow

    iOfficeAI/AionUi

    Sets the test-writing workflow for the repository: risk-first scenario lists, behavior-focused Vitest tests, a full run before each commit and a coverage target.

    33k GitHub starsUsed in 1 repo~1.2k tokens
    Testing & QAAuto-check passed
  • Designing Tests

    CloudAI-X/claude-workflow-v2

    Designs and implements testing strategies for any codebase. An agent skill from CloudAI-X/claude-workflow-v2.

    1.4k GitHub starsUsed in 1 repo~1.5k tokens
    Testing & QAAuto-check passed
  • Write Tests

    grafana/synthetic-monitoring-app

    Official

    Write Jest integration and unit tests for the Grafana Synthetic Monitoring app using React Testing Library, MSW, and src/test helpers.

    171 GitHub stars~1.2k tokensUpdated today
    Testing & QAAuto-check passed
  • Playwright Testing

    chongdashu/vibejam-starter-pack

    Plan, implement, and debug frontend tests: unit/integration/E2E/visual/a11y.

    149 GitHub stars~2.1k tokensUpdated 5 mo ago
    Testing & QAAuto-check passed

More from Ohh-889/skyroc

All 18 skills in this repo
  • UI Styling

    Ohh-889/skyroc

    Create beautiful, accessible user interfaces with shadcn/ui components (built on Radix UI + Tailwind), Tailwind CSS utility-first styling, and canvas-based visual designs.

    795 GitHub starsUsed in 13 repos~2.5k tokens
    Auto-check passed
  • Design System

    Ohh-889/skyroc

    Token architecture, component specifications, and slide generation.

    795 GitHub starsUsed in 11 repos~1.7k tokens
    Auto-check passed
  • Brand

    Ohh-889/skyroc

    Brand voice, visual identity, messaging frameworks, asset management, brand consistency.

    795 GitHub starsUsed in 13 repos~733 tokens
    Auto-check passed
  • Senior Frontend

    Ohh-889/skyroc

    Comprehensive frontend development skill for building modern, performant web applications using ReactJS, NextJS, TypeScript, Tailwind CSS.

    795 GitHub starsUsed in 2 repos~1.1k tokens
    Auto-check: notes
  • Design

    Ohh-889/skyroc

    Comprehensive design skill: brand identity, design tokens, UI styling, logo generation (55 styles, Gemini AI), corporate identity program (50 deliverables, CIP mockups), HTML presentations…

    795 GitHub starsUsed in 9 repos~3.1k tokens
    Auto-check passed
  • Frontend Code Review

    Ohh-889/skyroc

    Trigger when the user requests a review of frontend files (e.g., .tsx, .ts, .js).

    795 GitHub starsUsed in 3 repos~711 tokens
    Auto-check passed

Categories

Questions about Frontend Testing

What does Frontend Testing do?

Generate Vitest + React Testing Library tests for Dify frontend components, hooks, and utilities. Frontend Testing is an agent skill from Ohh-889/skyroc. Generate Vitest + React Testing Library tests for Dify frontend components, hooks, and utilities.

When should I use Frontend Testing?

Frontend Testing fits situations like: integration tests; write/review test requests.

How do I install Frontend Testing in Claude Code?

Run `npx skills add Ohh-889/skyroc --skill frontend-testing -a claude-code`. Or copy the skill folder (.agents/skills/frontend-testing in Ohh-889/skyroc) into .claude/skills/frontend-testing in your project. Claude Code loads it when a task matches its description.

How do I install Frontend Testing in Codex?

Run `npx skills add Ohh-889/skyroc --skill frontend-testing -a codex`. Or copy the skill folder (.agents/skills/frontend-testing in Ohh-889/skyroc) into .agents/skills/frontend-testing in your project. Codex loads it when a task matches its description.

Can I use Frontend Testing in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add Ohh-889/skyroc --skill frontend-testing -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/frontend-testing, .gemini/skills/frontend-testing, .github/skills/frontend-testing and .opencode/skills/frontend-testing in your project.

What does Frontend Testing need to run?

Going by SKILL.md and its folder, Frontend Testing needs TypeScript for the scripts in its folder and the command-line tools its instructions call (pnpm). Our summary lists: Node.js.

Does Frontend Testing access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Frontend Testing safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Frontend Testing use?

Frontend Testing is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Frontend Testing use?

About 2.5k tokens (SKILL.md is roughly 10k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 16k tokens, read only when the agent opens those files.

What are the alternatives to Frontend Testing?

Skills that share tags, products or a category with Frontend Testing: Hilla Test (AI-Unified-Process/marketplace, 141 stars), Dify Frontend Testing (langgenius/dify, 158k stars), Test Writing Workflow (iOfficeAI/AionUi, 33k stars) and Designing Tests (CloudAI-X/claude-workflow-v2, 1.4k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Frontend Testing?

Ohh-889 (a GitHub user) maintains it in Ohh-889/skyroc, which has 795 GitHub stars. The repository holds 18 skills in this directory. The repository was last updated on September 1, 2026.

Source: Ohh-889/skyroc on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.