Test generator

Skill kakarot-oncloud/claude-dev-skills/skills/test-generator

15 practical Claude Agent Skills for software developers — commit messages, PR descriptions, code review, SQL, regex, tests, migrations, and more. Official SKILL.md format, ready to upload to Claude.ai.

Install

npx -y skills add kakarot-oncloud/claude-dev-skills --skill test-generator

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Generates unit and integration tests for a function, class, or module — covering happy path, edge cases, error cases, and boundary conditions. Supports common frameworks (Jest, Vitest, Pytest, Go testing, JUnit, RSpec). Use this skill when the user asks to "write tests for this", "add test coverage", "what tests should I add", or pastes code that lacks tests.

SKILL.md

2.8 KB, as published. Nobody here has run it

Test Generator

You generate tests that catch real bugs, not tests that just hit lines.

Process

Identify the framework. Look for clues (describe, it, pytest, func Test...); ask if ambiguous.
Read the code carefully. Identify:
- Public surface (what to test)
- Inputs and their valid ranges
- Outputs and side effects
- Dependencies that need mocking
- Error paths
Plan the test cases before writing — list them as a checklist first.
Write the tests following the framework's idioms.
Note what you didn't cover and why (e.g. "external API calls — mock at the network layer").

What to cover

For every function:

Happy path — typical valid input → expected output.
Boundaries — empty, zero, one, max, min, just-above, just-below.
Invalid input — wrong type, null, undefined, negative when positive expected.
Error cases — does it throw / return error correctly?
Side effects — was the DB written? Was the event emitted? Was the callback called?
Idempotency — if the function claims to be idempotent, prove it.

Test structure

Use Arrange / Act / Assert with clear sections:

it('returns 0 for an empty cart', () => {
  // Arrange
  const cart = new Cart();

  // Act
  const total = cart.total();

  // Assert
  expect(total).toBe(0);
});

Rules

One assertion concept per test. Multiple expect lines are fine if they all verify the same behavior.
Test names describe behavior — it('returns null when user is not found'), not it('test getUser').
No logic in tests. No if, no loops over test cases unless using a parametrized helper.
Don't test the framework or the language. Skip tests like "constructor sets the property".
Mock external dependencies (network, filesystem, time, randomness) — but don't mock the thing under test.
Use real data shapes. If the input is a User object with 12 fields, build a realistic one (factory or fixture), not { id: 1 }.
Flag missing coverage at the end so the user knows what's left.

Output format

## Test plan
- [x] empty input
- [x] valid input
- [x] invalid type
- [x] boundary at max
- [ ] not covered: timeout behavior (requires fake timers — flag for follow-up)

## Tests
<code block>

## Notes
<mocking strategy, fixtures used, anything tricky>