agentleFS
kakarot-oncloudkakarot-oncloud/claude-dev-skills/skills/test-generator/SKILL.md

test-generator

Skill0 starsChanged 7 months agoMITView on GitHub

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.

25 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use refactor-advisor, log-analyzer and 3 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • aidankaokaoSkill

    refactor-advisor

    分析程式碼的重構機會,給出有優先順序的建議,但不直接改寫程式碼。當使用者說「這段程式碼怎麼改比較好」、「幫我分析重構方向」、「這樣寫有什麼問題」、「refactor」、「技術債」時觸發。

    Also in 3 projects that use this

  • nek1987Skill

    log-analyzer

    Parse and analyze application logs to identify errors, patterns, and insights.

    Also in 3 projects that use this

  • JeffallanSkill

    security-reviewer

    Identifies security vulnerabilities, generates structured audit reports with severity ratings, and provides actionable remediation guidance. Use when conducting security audits, reviewing code for vulnerabilities, or analyzing infrastructure security. Invoke for SAST scans, penetration testing, DevSecOps practices, cloud security reviews, dependency audits, secrets scanning, or compliance checks. Produces vulnerability reports, prioritized recommendations, and compliance checklists.

    Also in 3 projects that use this

  • Microsoft AzureSkill

    git-workflow

    Squad branching model: dev-first workflow with insiders preview channel

    Also in 3 projects that use this

  • GoogleSkill

    code-review

    Adversarial systems, concurrency, memory-model, and architecture code review protocol. Use this skill whenever asked to review code, PRs, diffs, or branches in Filament.

    Also in 4 projects that use this

The file

We split this skill into the rules it gives an agent

4 rules. 0 are common, 2 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 15 edited versions we read keep these.

  • 2

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Identify the framework: Look for clues (describe, it, pytest, func Test...).

    line 12
  2. Distinctive:

    Plan the test cases: before writing — list them as a checklist first.

    line 19
  3. Distinctive:

    Use Arrange / Act / Assert with clear sections:

    line 36
  4. Very specific:

    Use real data shapes: If the input is a User object with 12 fields, build a realistic one (factory or fixture), not { id: 1 }.

    line 58

“Common” is measured: kept by at least 6 in 10 of the 15 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Test Generator

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

Process

  1. Identify the framework. Look for clues (describe, it, pytest, func Test...); ask if ambiguous.
  2. 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
  3. Plan the test cases before writing — list them as a checklist first.
  4. Write the tests following the framework's idioms.
  5. 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

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

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.