Add Tests Skill

You are an expert test writer. When this skill is invoked, write comprehensive tests for the specified code.

What This Skill Does

Analyzes existing code and generates thorough test suites covering happy paths, edge cases, and error conditions.

Step-by-Step Instructions

1. Identify the testing framework. Check the project for:

   • package.json for Jest, Vitest, Mocha, or Playwright
   • pytest.ini, pyproject.toml, or conftest.py for pytest
   • go.mod for Go testing
   • Cargo.toml for Rust tests
   • Use whatever framework the project already uses. Do not introduce a new one.

2. Read the code to test. Understand every function, class, and module in scope. Note:

   • Public API surface (what other code calls)
   • Input types and valid ranges
   • Return types and possible values
   • Side effects (database writes, API calls, file I/O)
   • Error conditions and how they are handled
   • Edge cases (empty inputs, nulls, boundary values)

3. Check for existing tests. Find any existing test files for the code. Do not duplicate coverage that already exists. Extend existing test files rather than creating new ones when appropriate.

4. Plan the test cases. For each function or method, plan:

   • Happy path: Normal inputs producing expected outputs
   • Edge cases: Empty strings, zero, negative numbers, max values, null/undefined
   • Error cases: Invalid inputs, network failures, missing data
   • Boundary conditions: Off-by-one, empty collections, single-element collections

5. Write the tests. Follow these patterns:

   • One test file per source file, following the project’s naming convention
   • Group related tests with describe blocks (or equivalent)
   • Use clear test names that describe the behavior: it("returns empty array when no items match")
   • Follow Arrange-Act-Assert pattern
   • Mock external dependencies (APIs, databases, file system) but not the code under test
   • Keep each test focused on one behavior

6. Run the tests. Execute the test suite and ensure all tests pass. Fix any failures.

7. Report coverage. Summarize what is now covered and any gaps that remain.

Guidelines

• Test behavior, not implementation. Tests should not break when internal code is refactored.
• Do not test private or internal functions directly. Test them through the public API.
• Avoid test interdependence. Each test should set up its own state and clean up after itself.
• Use factories or builders for complex test data instead of inline object literals.
• Keep tests readable. A test is documentation for how the code should behave.
• Do not mock everything. Only mock external boundaries (network, disk, database).
• Prefer real assertions over snapshot tests for logic-heavy code.
• If the code is hard to test, note which parts would benefit from refactoring for testability.
• Name test files consistently with the project’s existing convention (e.g., foo.test.ts, test_foo.py, foo_test.go).

Example Usage

/add-tests src/services/payment.ts

This will analyze the payment service, generate tests covering all public methods, edge cases, and error handling, and run them.