/generate-tests

name: generate-tests
description: "Use when asked to generate tests for a file, module or component, to raise coverage, or to bootstrap a suite for untested code. Detects the project's test framework and conventions first, then writes unit, integration and edge-case tests."
domain: engineering
supports: [claude-code, cursor, codex, generic]
version: 0.1.0

Generate Tests — Comprehensive Test Suite Generator

Generate complete test coverage for any file, component, or module. Covers unit tests, integration tests, edge cases, error handling, and mocking — adapted to whatever testing framework the project uses.

**Use when**: you want tests generated for a file or component, need to improve test coverage, want edge case coverage, need mocks for external dependencies, or want to bootstrap a test suite for untested code.

---

When This Skill Is Activated

Follow every step below. Do NOT generate tests without first analyzing the project's testing setup and the target code.

---

Step 1: Detect the Testing Setup

Before writing any tests, discover the project's testing conventions:

1. **Find the test framework** — Check `package.json` (dependencies/scripts), or config files:

• `jest.config.*` / `jest` key in `package.json` → Jest
• `vitest.config.*` → Vitest
• `cypress.config.*` → Cypress
• `playwright.config.*` → Playwright
• `pytest.ini` / `pyproject.toml` [tool.pytest] → pytest
• `go.mod` → Go testing
• `Cargo.toml` → Rust (#[cfg(test)])

2. **Find existing test files** — Search for `*.test.*`, `*.spec.*`, `test_*.py`, `*_test.go` to understand naming conventions and patterns already in use.

3. **Check for test utilities** — Look for shared helpers, factories, custom matchers, or mock setups the project already provides (e.g., `test/utils.ts`, `__mocks__/`, `conftest.py`).

4. **Check the test script** — Read the `test` script in `package.json` (or equivalent) to understand how tests are run, what flags are used, and what coverage tool is configured.

**Match the project's existing conventions exactly.** File naming, import style, assertion style, describe/it vs test, etc.

---

Step 2: Analyze the Target Code

Read the file or component the user wants tested. Identify:

• All exported functions, classes, methods, and components
• Input types and return types (or infer them)
• External dependencies (API calls, database, file system, third-party libs)
• Side effects (mutations, network calls, timers, DOM manipulation)
• Error paths (throw statements, catch blocks, error returns)
• Edge cases (null/undefined inputs, empty arrays, boundary values, large inputs)
• Async behavior (promises, callbacks, streams)

---

Step 3: Plan the Test Suite

Before writing code, outline what you'll test:

Unit Tests

• Every exported function with representative inputs
• Return values for happy path
• Error handling for invalid inputs
• Boundary values (0, -1, empty string, null, max int, etc.)
• Type coercion edge cases if applicable

Integration Tests (if the code interacts with other modules)

• Component interactions and data flow
• API calls with mocked responses (success + failure)
• Service layer with mocked dependencies
• State management side effects

Edge Cases and Error Handling

• Null, undefined, empty inputs
• Malformed data
• Network failures / timeouts
• Concurrent access / race conditions
• Extremely large inputs

---

Step 4: Write the Tests

Follow these principles:

Structure

describe("[ModuleName]", () => {
  describe("[functionName]", () => {
    it("should [expected behavior] when [condition]", () => {
      // Arrange
      // Act
      // Assert
    });
  });
});

• **Descriptive test names** — Read like documentation: "should return empty array when input is null"
• **AAA pattern** — Arrange (setup), Act (execute), Assert (verify). Separate each visually.
• **One assertion per concept** — Multiple `expect()` calls are fine if they assert one logical thing
• **Group with `describe`** — One block per function/method/component behavior
• **Setup/teardown** — Use `beforeEach`/`afterEach` for test isolation. Clean up subscriptions, timers, mocks.

Mocking Strategy

• Mock **external dependencies only** — Don't mock the code under test
• Use the project's existing mock patterns (e.g., `jest.mock()`, `vi.mock()`, `unittest.mock`)
• Create **test data factories** for complex objects instead of inline literals
• Mock timers (`jest.useFakeTimers()` / `vi.useFakeTimers()`) for time-dependent code
• Mock dates for deterministic snapshots
• Always **restore mocks** in `afterEach` to prevent test pollution

Async Testing

• Always `await` async functions or return the promise
• Test both resolve and reject paths
• Use `waitFor` / `findBy` for async UI updates (React Testing Library)
• Test loading, success, and error states

Framework-Specific Guidance

| Framework | Component Testing | Key Patterns | |-----------|------------------|--------------| | **React** | React Testing Library | `render()`, `screen.getByRole()`, `userEvent`, `waitFor` | | **Vue** | Vue Test Utils | `mount()`, `shallowMount()`, `wrapper.find()`, `trigger()` | | **Angular** | TestBed | `TestBed.configureTestingModule()`, `fixture.detectChanges()` | | **Node.js** | Supertest | `request(app).get("/api/...").expect(200)` | | **Python** | pytest | `@pytest.fixture`, `monkeypatch`, parametrize | | **Go** | testing | `t.Run()`, table-driven tests, `t.Parallel()` |

---

Step 5: Verify and Improve

After generating the tests:

1. **Run the tests** — Execute the test suite to make sure they pass 2. **Check coverage** — Identify untested lines or branches 3. **Add missing cases** — Fill gaps in coverage, especially error paths 4. **Review test quality** — Tests should fail when the code breaks, not just when the tests break

Coverage Goals

| Priority | Coverage Target | |----------|----------------| | Critical business logic | 90%+ | | Utility f