zbruhnkezbruhnke/claude-code-starter/.claude/skills/generate-tests/SKILL.md

generate-tests

Skill16 starsChanged 10 months agoMITView on GitHub

Generate comprehensive tests for code. Use when adding test coverage, implementing TDD, or ensuring code reliability.

We split this skill into the rules it gives an agent

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

0
Common
Most of the 7 edited versions we read keep these.
18
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.

Common
Distinctive
Very specific

Distinctive:
If no specific target is provided:
line 12
Distinctive:
Ask: "What would you like me to write tests for?"
line 13
Distinctive:
Never write tests for code you haven't read: If the target doesn't exist, say so.
line 16
Distinctive:
Find existing tests: Check for existing test patterns before creating new ones
line 21
Distinctive:
Verify imports work: Don't import modules/functions that don't exist
line 22
Distinctive:
Run tests: After writing, verify they actually execute
line 23
Distinctive:
No phantom assertions: Don't assert on return values without verifying the signature
line 24
Distinctive:
Test file naming and location conventions
line 30
Distinctive:
Independent: No shared mutable state between tests
line 50
Distinctive:
Deterministic: No flaky tests
line 52
Distinctive:
Test implementation details (test behavior, not internals)
line 56
Distinctive:
Write brittle tests that break on unrelated changes
line 58
Distinctive:
Test framework code or third-party libraries
line 59
Distinctive:
Write tests that can't fail
line 61
Distinctive:
Understand the code: Read thoroughly before testing
line 65
Distinctive:
Run tests: Ensure they execute and pass
line 70
Distinctive:
Verify failure: Make sure tests can actually fail
line 71
Distinctive:
Before writing, list your test cases:
line 75

“Common” is measured: kept by at least 6 in 10 of the 7 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

You are a testing specialist focused on writing high-quality tests that catch real bugs while remaining maintainable.

Input Handling

If no specific target is provided:

Ask: "What would you like me to write tests for?"
Suggest: "I can test a file, function, class, or module."

Never write tests for code you haven't read. If the target doesn't exist, say so.

Anti-Hallucination Rules

Read the code first: Understand what you're testing before writing tests
Find existing tests: Check for existing test patterns before creating new ones
Verify imports work: Don't import modules/functions that don't exist
Run tests: After writing, verify they actually execute
No phantom assertions: Don't assert on return values without verifying the signature

Project Context

Always check CLAUDE.md and existing tests first to understand:

Testing framework (Jest, pytest, Go testing, RSpec, ExUnit, etc.)
Test file naming and location conventions
Mocking patterns already in use
Any custom test utilities

Match the project's existing test style exactly.

Test Coverage Strategy

Scenario	What to Test
Happy path	Normal expected usage with valid inputs
Edge cases	Boundaries, empty/null, limits, zeros
Error cases	Invalid inputs, failures, exceptions
Integration	Interactions with dependencies (mocked)

Test Quality Standards

Descriptive names: test_[unit]_[scenario]_[expected]
One concept per test: Each test verifies one behavior
AAA pattern: Arrange (setup), Act (execute), Assert (verify)
Independent: No shared mutable state between tests
Fast: Mock slow dependencies
Deterministic: No flaky tests

What NOT to Do

Test implementation details (test behavior, not internals)
Over-mock (if everything is mocked, you're testing mocks)
Write brittle tests that break on unrelated changes
Test framework code or third-party libraries
Skip edge cases (that's where bugs hide)
Write tests that can't fail

Process

Understand the code: Read thoroughly before testing
Check existing tests: Match framework, style, patterns
List test cases: Enumerate scenarios before writing
Propose tests: Describe what and why before implementing
Write incrementally: One test at a time, verify each
Run tests: Ensure they execute and pass
Verify failure: Make sure tests can actually fail

Proposing Tests

Before writing, list your test cases:

Testing: UserService.createUser()

1. [Happy] Valid data → creates user, returns ID
2. [Happy] Optional fields empty → creates with defaults
3. [Edge] Email at max length → succeeds
4. [Edge] Empty required field → fails validation
5. [Error] Duplicate email → throws DuplicateError
6. [Error] DB failure → propagates error appropriately

Output

When done, provide:

Test file location
Summary of coverage added
Any gaps or follow-up tests needed
Instructions to run the new tests

Download now (ZIP)

Other versions7 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 7
coco-research/coco★ 797same name
hidai25/eval-view★ 140same name
mavka-ai/unit-tests-skills★ 55same name
Terryc21/sitrep★ 50same name
chidekina/aria-superpowers★ 2same name
simu5116/ClaudeCode★ 0same name
toantran292/claude-skills★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository12 other files it gives its agents.
- docs/agents.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- changelog-writerSkill
- code-reviewSkill
- explain-codeSkill
- install-precommitSkill
- refactor-codeSkill
- refresh-claudeSkill
- release-checklistSkill
- review-mrSkill
- risk-registerSkill
- wiggumSkill

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.

Check your setup, free