About this skill

Problem

Writing unit tests often becomes repetitive work: reading source code, identifying the test framework, respecting file placement conventions, and covering boundary and error paths. This skill targets Python, JavaScript/TypeScript, Java, Go, C/C++, Rust, and C# projects. It generates maintainable test files from source code without modifying business code.

How it works

The skill proceeds through four phases. It first discovers the project: language, test framework, source and test directories, naming rules, and existing mock conventions. It then analyzes target functions for signatures, control flow, data flow, dependencies, side effects, and error paths. It designs three levels of cases: happy path, edge/boundary, and error/exception. Finally, it writes tests in the project's style, using Arrange-Act-Assert, descriptive names, parameterized or table-driven cases, and the project's preferred mock library. Language-specific references help apply idiomatic patterns for Python, JS/TS, Java, Go, C/C++, Rust, and C#.

Boundaries and notes

The skill only creates or updates test files and does not modify source files. It avoids calling real networks, databases, or third-party APIs, and skips generated code, framework boilerplate, and vendored code. If a test file already exists, it adds new tests without deleting or changing existing ones unless requested. For languages not explicitly listed, it relies on existing project tests to infer conventions.

Screenshots

Use Cases

Before a Python service change, add boundary and exception tests to a new order validation function.
When refactoring a JS utility package, generate table-driven tests for a string parser using existing jest conventions.
Before releasing a Go payment module, add happy-path, boundary, and timeout tests for refund state transitions.
During a Rust parser audit, generate edge tests for error paths and Unicode inputs.

Best For

Backend engineers maintaining Python services who need to fill in boundary and exception tests for validation logic.
Frontend or Node engineers taking over JS/TS utility libraries who need to add cases under the existing test framework.
Go or Rust engineers responsible for release quality who need error-path and dependency-failure coverage.
Tech leads reviewing or refactoring code who need review-ready tests for newly added functions.