generate-tests

# 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 functions | 85%+ | | UI components | 80%+ | | Configuration/glue code | 60%+ | Focus on **branch coverage** over line coverage — untested `else` and `catch` paths are where bugs hide. --- ## Output Checklist Before finishing, verify: - [ ] Tests follow the project's existing naming convention and file location - [ ] All exported functions/components have at least one test - [ ] Happy path tested for every function - [ ] Error/failure path tested for every function that can fail - [ ] Edge cases covered (null, empty, boundary values) - [ ] External dependencies are mocked (no real API calls, no real DB) - [ ] Async code is properly awaited - [ ] Mocks are cleaned up in afterEach - [ ] Tests are independent — can run in any order - [ ] Test names read like documentation