Provides conventions for organizing and implementing unit tests in the S2 framework.
Install
mkdir -p .claude/skills/s2-unit-test && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/7085" && unzip -o skill.zip -d .claude/skills/s2-unit-test && rm skill.zipInstalls to .claude/skills/s2-unit-test
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Guidelines for writing and maintaining unit tests in the S2 project. Use when modifying source code to ensure proper test coverage.Key capabilities
- →Locate test files by module
- →Verify bug fixes with regression tests
- →Ensure test coverage for new features
- →Import source code for testing
How it works
The skill provides a directory-based strategy for placing tests and requires that all tests import and exercise actual source code to ensure coverage.
Inputs & outputs
When to use s2-unit-test
- →Verify bug fixes with regression tests
- →Add unit tests for new utility functions
- →Locate appropriate test files for existing modules
About this skill
S2 Unit Testing Guidelines
When to Use This Skill
Use this skill when you:
- Modify code under
packages/*/src/ - Fix bugs (especially with issue numbers)
- Add new features or functions
By default, all code changes require corresponding unit tests.
Test File Location Strategy
Step 1: Find Existing Test Files
Search for __tests__ directories to find where tests for the modified file already exist:
packages/s2-core/__tests__/unit/ # Unit tests organized by module
packages/s2-core/__tests__/bugs/ # Bug regression tests with issue numbers
packages/s2-core/__tests__/spreadsheet/ # Integration-level spreadsheet tests
packages/s2-react/__tests__/ # React component tests
packages/s2-vue/__tests__/ # Vue component tests
Step 2: Choose the Right Location
| Scenario | Location | File Naming |
|---|---|---|
| Modifying existing function | Add to existing test file for that function | N/A |
| Bug fix with issue number | packages/s2-core/__tests__/bugs/ | issue-{number}-spec.ts |
| New utility function | packages/s2-core/__tests__/unit/utils/ | {function-name}-spec.ts |
| New cell logic | packages/s2-core/__tests__/unit/cell/ | {cell-type}-spec.ts |
| New interaction | packages/s2-core/__tests__/unit/interaction/ | {interaction-name}-spec.ts |
Prefer adding tests to existing files over creating new ones. Reuse existing helper functions and test utilities.
Critical Rules
✅ Good Practices
- Import from
srcdirectory - Tests must exercise actual source code:
// Good: Import functions/classes from src
import { getCellWidth, getDisplayText } from '@/utils/text';
import { PivotSheet } from '@/sheet-type';
// Good: Use path aliases
import { createPivotSheet } from 'tests/util/helpers';
- Test real behavior - Create actual instances and verify logic:
// Good: Create real S2 instance and test behavior
const s2 = createPivotSheet(options);
await s2.render();
expect(s2.facet.getColCells()[0].getMeta().width).toBe(expectedWidth);
- Reproduce bugs with real code paths:
// Good: Bug reproduction that exercises src code
describe('issue #3212', () => {
test('should keep column width after hiding value', async () => {
const s2 = createPivotSheet({ style: { layoutWidthType: 'compact' } });
await s2.render();
const originalWidth = s2.facet.getColCells()[0].getMeta().width;
s2.setOptions({ style: { colCell: { hideValue: true } } });
await s2.render();
expect(s2.facet.getColCells()[0].getMeta().width).toBe(originalWidth);
});
});
❌ Bad Practices
- Never reimplement logic in tests:
// BAD: Reimplementing the logic defeats the purpose
function myLocalCalculation(a, b) {
return a + b; // This is useless! If src is broken, test still passes
}
expect(myLocalCalculation(1, 2)).toBe(3);
- Never import only types:
// BAD: Only importing types doesn't test any actual code
import type { S2Options, SpreadSheet } from '@/common';
// No actual code is being tested!
- Never test mocked implementations instead of real code:
// BAD: Testing your own mock, not the actual source
const mockFn = jest.fn().mockReturnValue(42);
expect(mockFn()).toBe(42); // This tests nothing useful
Test Structure Template
/**
* @description spec for issue #XXXX (if applicable)
* https://github.com/antvis/S2/issues/XXXX
*/
import { SomeFunction, SomeClass } from '@/path/to/src';
import { createPivotSheet } from 'tests/util/helpers';
describe('FeatureName', () => {
test('should do expected behavior', () => {
// Arrange
const input = { /* ... */ };
// Act
const result = SomeFunction(input);
// Assert
expect(result).toEqual(expectedOutput);
});
});
Running Tests
# Run all tests for a package
pnpm --filter @antv/s2 test
# Run specific test file
pnpm --filter @antv/s2 test -- --testPathPattern="issue-3212"
# Run with coverage
pnpm --filter @antv/s2 test:coverage
Goal
The primary goal of unit tests is to:
- Increase line coverage - Every line of src code should be exercised
- Increase branch coverage - Test all conditional paths
- Prevent regressions - Ensure bugs don't reappear
Tests that don't import and exercise actual src code provide no coverage benefit.
When not to use it
- →Testing mocked implementations
- →Reimplementing source logic in tests
Prerequisites
Limitations
- →Tests must import from src directory
- →Requires existing test utilities
How it compares
It enforces a strict project-specific testing structure that prioritizes real code execution over mocking, unlike generic testing approaches.
Compared to similar skills
s2-unit-test side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| s2-unit-test (this skill) | 1 | 6mo | Review | Intermediate |
| react-best-practices | 22 | 3mo | No flags | Intermediate |
| feature-flags | 6 | 6mo | Review | Intermediate |
| playwright-validation | 3 | 5mo | Review | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by antvis
View all by antvis →You might also like
react-best-practices
redpanda-data
Client-side React performance optimization patterns.
feature-flags
Use when feature flag tests fail, flags need updating, understanding @gate pragmas, debugging channel-specific test failures, or adding new flags to React.
playwright-validation
open-metadata
Use when validating UI changes in a branch require Playwright E2E testing. Reviews branch changes, validates UI with Playwright MCP, and adds missing test cases.
senior-qa
alirezarezvani
This skill should be used when the user asks to "generate tests", "write unit tests", "analyze test coverage", "scaffold E2E tests", "set up Playwright", "configure Jest", "implement testing patterns", or "improve test quality". Use for React/Next.js testing with Jest, React Testing Library, and Playwright.
react-component-performance
Dimillian
Analyze and optimize React component performance issues (slow renders, re-render thrash, laggy lists, expensive computations). Use when asked to profile or improve a React component, reduce re-renders, or speed up UI updates in React apps.
frontend-review
yukihito-jokyu
フロントエンド(TypeScript/CSS/E2Eテスト)の変更点を自動検証(Biome/Playwright)および目視レビューし、プロジェクト特有のルールや一般的なベストプラクティスを検証するスキル。