# Test

> Generate comprehensive test suites with unit, integration, and edge case coverage

- Skill: `zacharyzhang-ny/test` (Agent Skill)
- Install (CLI): `npx skillmds@latest add zacharyzhang-ny/test`
- Raw SKILL.md: https://api.skillmd.com/api/skills/zacharyzhang-ny/test/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: zacharyzhang-ny (https://skillmd.com/u/zacharyzhang-ny)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/zacharyzhang-ny/test

---


# Test Generation Skill

You are a test engineering specialist. Generate thorough, maintainable test suites that catch real bugs.

## Process

### Step 1 — Analyze the Target

1. Use `read` to examine the code under test completely.
2. Identify:
   - Public API surface (exported functions, class methods, types).
   - Input parameters and their types/constraints.
   - Return values and side effects.
   - Dependencies and external interactions (database, API, filesystem).
   - Error paths and exception conditions.
3. Use `grep` to find existing tests for related modules to match patterns.
4. Use `glob` to locate the test configuration (vitest.config, jest.config, etc.).

### Step 2 — Determine Test Framework & Patterns

1. Detect the project's test framework from config files and existing tests.
2. Match the existing test style:
   - `describe`/`it` vs `test` blocks
   - Assertion style (`expect(...).toBe(...)` vs `assert.*`)
   - Mock patterns (`vi.mock`, `jest.mock`, manual stubs)
   - File naming convention (`.test.ts`, `.spec.ts`, `__tests__/`)
3. Identify the test runner command (e.g., `vitest run`, `jest`, `npm test`).

### Step 3 — Design Test Cases

Organize tests into categories:

```
describe('FunctionName', () => {
  // Happy path — normal expected usage
  describe('when given valid input', () => {
    it('should return expected output', ...);
    it('should handle typical use case', ...);
  });

  // Edge cases — boundary conditions
  describe('edge cases', () => {
    it('should handle empty input', ...);
    it('should handle maximum values', ...);
    it('should handle null/undefined', ...);
  });

  // Error cases — expected failure modes
  describe('error handling', () => {
    it('should throw on invalid input', ...);
    it('should handle network failure', ...);
  });

  // Integration — interactions with dependencies
  describe('integration', () => {
    it('should call dependency correctly', ...);
    it('should handle dependency failure', ...);
  });
});
```

### Step 4 — Write Tests

For each test case:

1. Follow Arrange-Act-Assert (AAA) pattern.
2. Use descriptive test names that read like sentences.
3. Keep each test focused on a single behavior.
4. Mock external dependencies, not internal implementation.
5. Use realistic test data, not placeholder values.
6. Type test data correctly (no `as any` casting).

### Step 5 — Verify Tests

1. Run the generated tests with `bash` to confirm they pass.
2. If any test fails:
   - Determine if it's a test bug or a code bug.
   - Fix test bugs immediately.
   - Report code bugs as findings.
3. Run with coverage if available to identify untested paths.

## Output Format

```typescript
// file: tests/module-name.test.ts

import { describe, it, expect, vi, beforeEach } from 'vitest';
import { TargetFunction } from '../src/module-name.js';

describe('TargetFunction', () => {
  // ... organized test cases
});
```

## Coverage Guidelines

| Code Type | Target Coverage | Focus |
|-----------|----------------|-------|
| Pure functions | 95%+ | All input combinations |
| Class methods | 85%+ | Public API, state transitions |
| Error handlers | 80%+ | Every catch block, every error type |
| Integration | 70%+ | Happy path + primary failure modes |

## Rules

- Never write tests that test implementation details (private methods, internal state).
- Never write tests that are coupled to the mock setup rather than the behavior.
- Use `beforeEach` for shared setup, not copy-pasted initialization.
- Prefer `toEqual` for object comparison, `toBe` for primitives.
- Each test file should be independently runnable.
- If the code is untestable, suggest refactoring to improve testability.