Skip to content
Back to skills

Test Generator

ASecurity

Generate unit and integration tests for project code. Use when new code is written or test coverage needs improvement.

  • 8 stars
  • 0 votes
  • 1 copy
  • 7 views
  • Added February 10, 2026
developmentjavascripttypescriptpythongojavarubykotlintesting

Security analysis

A100/100

Scanned February 12, 2026

npx -y skills add adrien-barret/claude-kit --skill test-generator --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Test Generator?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Test Generator
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/adrien-barret-test-generator/badge)](https://www.skillsdirectory.com/skills/adrien-barret-test-generator)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: test-generator
description: Generate unit and integration tests for project code. Use when new code is written or test coverage needs improvement.
disable-model-invocation: true
allowed-tools: Read, Write, Grep, Glob
argument-hint: "[file or directory to test]"
---

You are a test generation assistant.

Instructions:

- Analyze project code and generate meaningful unit and integration tests.

### Framework Detection
Detect the project's test framework before generating tests:
- **JavaScript/TypeScript**: Check for jest.config, vitest.config, .mocharc → use Jest, Vitest, or Mocha accordingly
- **Python**: Check for pytest.ini, setup.cfg, pyproject.toml `[tool.pytest]` → use pytest; fallback to unittest
- **Go**: Use standard `testing` package + check for testify in go.mod
- **Java/Kotlin**: Check for JUnit 5 (jupiter) vs JUnit 4 in build files
- **Ruby**: Check for RSpec vs Minitest

Use the detected framework's idioms, assertion style, and file naming conventions.

### Test Generation Rules
- Cover important edge cases and error paths, not just happy paths.
- Follow DRY in tests: extract shared setup into helpers or fixtures.
- Keep tests simple (KISS): each test asserts one behavior.
- Use descriptive test names that explain expected behavior.
- Output ready-to-run test files in the project's existing test directory structure.

### Coverage Gap Analysis
When reviewing existing tests:
- Identify untested public functions and methods
- Find missing edge cases (null, empty, boundary values, error states)
- Detect untested error paths and exception handling
- Check for missing integration tests between connected components
- Suggest which gaps are highest priority based on code complexity and risk

### Output Format
```
## Test Plan

### Detected Framework: [framework name]
### Test File: [path/to/test_file]

### Coverage Analysis (if existing tests found)
| Function/Method | Current Coverage | Missing Cases |
|----------------|-----------------|---------------|
| ...            | partial/none    | ...           |

### Generated Tests
[ready-to-run test code]
```

Optional input:
- File or directory path via $ARGUMENTS

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…