test-guard

Name: test-guard
Author: amElnagdy

2.1kinstalls128forks

How to install test-guard?

amelnagdy/guard-skills/test-guard

$npx -y skills add amElnagdy/guard-skills --skill test-guard

Installs into the current project.

Summary

Review generated or changed test code against universal testing rules before it ships. Best used reactively after an agent writes, edits, generates, or refactors tests, before presenting, committing, or merging them. Use for pytest (test_*.py, *_test.py), PHPUnit/Pest (*Test.php)

Files · 1

View on GitHub

SKILL.md

1	# Test Guard
2
3	You are reviewing generated or changed test code before it ships. Enforce the rules below after the first test-writing pass and before the tests are presented, committed, or merged. Be a sharp reviewer, not a pedantic one: flag what wastes maintenance effort or hides real bugs, ignore cosmetic preferences.
4
5	These rules exist because coding agents over-generate tests. The common failure modes: mock-heavy unit tests that assert implementation details, near-duplicate test bodies that differ by one value, and tests that re-verify the framework instead of the project's logic. Each looks productive in a diff and costs maintenance forever.
6
7	## When this skill activates
8
9	- A coding agent has just written new test functions or test files, in any language
10	- You are editing existing tests
11	- You are reviewing a diff that contains test changes
12	- The user asks you to write, add, or review tests
13
14	## Adapt to the project first
15
16	These rules are universal, but their application is not. Before reviewing:
17
18	1. Check the project's own agent instructions (CLAUDE.md, AGENTS.md) and testing docs. Project-specific testing rules win over this skill when they conflict.
19	2. Identify the test stack, then read the matching reference for concrete patterns:
20	- Python / pytest → [references/pytest.md](references/pytest.md)
21	- PHP / PHPUnit / Pest / WordPress → [references/phpunit.md](references/phpunit.md)
22	- JavaScript / TypeScript / Jest / Vitest → [references/jest.md](references/jest.md)
23	3. If the project calls LLM APIs, uses agent frameworks, or wires up observability/telemetry, also read [references/llm-app-testing.md](references/llm-app-testing.md) — it adds three rules specific to LLM applications.
24	4. Map the project's system boundaries: network calls, databases, filesystem, clock and randomness, third-party SDKs, LLM APIs. Existing fixtures and test helpers usually reveal where the project already draws these lines.
25
26	## What to do
27
28	1. Read the test code: the diff, the new file, or the section being modified.
29	2. Check each test against the rules below.
30	3. Report violations concisely: rule number, location, why it violates, suggested fix.
31	4. If the user explicitly invokes this skill before test writing, apply the rules as you write — don't write violations and then flag them.
32
33	When writing new tests, ask for each test: "What specific bug does this catch that no other test in this suite catches?" If you can't answer clearly, don't write it.
34
35	## The Nine Rules
36
37	### Rule 1: Test behavior, not implementation
38	Test what code does from the caller's perspective. Assert return values and observable side effects. Never assert that an internal helper was called with specific arguments — that test breaks on every refactor while catching nothing.
39
40	Violation pattern: asserting a mock of an internal function was called, where that function is not a system boundary.
41	Fix: assert the return value or the state change the caller observes.
42
43	### Rule 2: Every mock must be justified
44	Mock only at system boundaries: network and HTTP calls, LLM APIs, databases, filesystem I/O on external files, clock and randomness, third-party SDKs. Never mock internal classes or helper functions to isolate a "unit" — the seams you create hide the integration bugs worth catching.
45
46	When you mock a boundary, assert what the caller does with the response, not that the mock received specific arguments.
47
48	### Rule 3: One scenario per test, data-driven for variants
49	If two or more tests share identical setup and differ only in input/output values, merge them into one data-driven test (`@pytest.mark.parametrize`, PHPUnit `#[DataProvider]`, Jest `test.each`).
50
51	When separate tests ARE correct: different setup, different assertions, different mock configurations, or genuinely different scenarios that happen to exercise the same function.
52
53	### Rule 4: Every test must justify its existence
54	Ask: "What bug does this catch that no other test catches?" Delete tests that only catch typos, verify default values of data classes, or test trivial pass-through logic.
55
56	Common unjustified tests: constructors setting attribut

People who liked this also viewed

6 picks

Type

test-guard

2.1kinstalls128forks

View on GitHub

How to install test-guard?

amelnagdy/guard-skills/test-guard

$npx -y skills add amElnagdy/guard-skills --skill test-guard

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Test Guard
2
3	You are reviewing generated or changed test code before it ships. Enforce the rules below after the first test-writing pass and before the tests are presented, committed, or merged. Be a sharp reviewer, not a pedantic one: flag what wastes maintenance effort or hides real bugs, ignore cosmetic preferences.
4
5	These rules exist because coding agents over-generate tests. The common failure modes: mock-heavy unit tests that assert implementation details, near-duplicate test bodies that differ by one value, and tests that re-verify the framework instead of the project's logic. Each looks productive in a diff and costs maintenance forever.
6
7	## When this skill activates
8
9	- A coding agent has just written new test functions or test files, in any language
10	- You are editing existing tests
11	- You are reviewing a diff that contains test changes
12	- The user asks you to write, add, or review tests
13
14	## Adapt to the project first
15
16	These rules are universal, but their application is not. Before reviewing:
17
18	1. Check the project's own agent instructions (CLAUDE.md, AGENTS.md) and testing docs. Project-specific testing rules win over this skill when they conflict.
19	2. Identify the test stack, then read the matching reference for concrete patterns:
20	- Python / pytest → [references/pytest.md](references/pytest.md)
21	- PHP / PHPUnit / Pest / WordPress → [references/phpunit.md](references/phpunit.md)
22	- JavaScript / TypeScript / Jest / Vitest → [references/jest.md](references/jest.md)
23	3. If the project calls LLM APIs, uses agent frameworks, or wires up observability/telemetry, also read [references/llm-app-testing.md](references/llm-app-testing.md) — it adds three rules specific to LLM applications.
24	4. Map the project's system boundaries: network calls, databases, filesystem, clock and randomness, third-party SDKs, LLM APIs. Existing fixtures and test helpers usually reveal where the project already draws these lines.
25
26	## What to do
27
28	1. Read the test code: the diff, the new file, or the section being modified.
29	2. Check each test against the rules below.
30	3. Report violations concisely: rule number, location, why it violates, suggested fix.
31	4. If the user explicitly invokes this skill before test writing, apply the rules as you write — don't write violations and then flag them.
32
33	When writing new tests, ask for each test: "What specific bug does this catch that no other test in this suite catches?" If you can't answer clearly, don't write it.
34
35	## The Nine Rules
36
37	### Rule 1: Test behavior, not implementation
38	Test what code does from the caller's perspective. Assert return values and observable side effects. Never assert that an internal helper was called with specific arguments — that test breaks on every refactor while catching nothing.
39
40	Violation pattern: asserting a mock of an internal function was called, where that function is not a system boundary.
41	Fix: assert the return value or the state change the caller observes.
42
43	### Rule 2: Every mock must be justified
44	Mock only at system boundaries: network and HTTP calls, LLM APIs, databases, filesystem I/O on external files, clock and randomness, third-party SDKs. Never mock internal classes or helper functions to isolate a "unit" — the seams you create hide the integration bugs worth catching.
45
46	When you mock a boundary, assert what the caller does with the response, not that the mock received specific arguments.
47
48	### Rule 3: One scenario per test, data-driven for variants
49	If two or more tests share identical setup and differ only in input/output values, merge them into one data-driven test (`@pytest.mark.parametrize`, PHPUnit `#[DataProvider]`, Jest `test.each`).
50
51	When separate tests ARE correct: different setup, different assertions, different mock configurations, or genuinely different scenarios that happen to exercise the same function.
52
53	### Rule 4: Every test must justify its existence
54	Ask: "What bug does this catch that no other test catches?" Delete tests that only catch typos, verify default values of data classes, or test trivial pass-through logic.
55
56	Common unjustified tests: constructors setting attribut

People who liked this also viewed

6 picks

Type