test-quality

Name: test-quality
Author: techygarg

165stars12forks

How to install test-quality?

techygarg/lattice/test-quality

$npx -y skills add techygarg/lattice --skill test-quality

Installs into the current project.

Summary

Apply test quality principles when generating or reviewing test code. Enforces Arrange-Act-Assert structure, one behavior per test, assertion quality, test isolation, meaningful naming, and test data management. Use when writing tests, reviewing test code, or when the user mentio

Files · 1

View on GitHub

SKILL.md

1	# Test Quality
2
3	## Config Resolution
4
5	Skill support project custom. Order:
6
7	1. Look `.lattice/config.yaml` in repo root
8	2. If find, check `paths.test_quality` for custom doc path
9	3. If custom path exist, read doc & check YAML frontmatter for `mode`:
10	- `mode: override` (or no mode): Custom doc take full control. Use instead default. Must be complete -- is only reference.
11	- `mode: overlay`: Read `./references/defaults.md` first, then apply custom doc on top. Custom sections replace match sections (by heading). New sections add after.
12	4. If no config/path/file, read `./references/defaults.md`
13	5. Language adaptation: If `paths.language_idioms` exist in config, read "Testing Patterns" section and adapt §5 (Test Naming), §4 (Test Isolation), §6 (Test Data Builders) to language test framework idioms. Language idioms take precedence over pseudocode defaults.
14
15	## Self-Validation Checklist
16
17	STOP after gen each test. Check ALL before continue. If fail, fix. If ambiguous (see Ambiguity Signals), flag -- show options & reasoning.
18
19	1. AAA STRUCTURE: arrange, act, assert separate w/ blank lines? Any logic (if/loop/try) in arrange or assert?
20	2. SINGLE BEHAVIOR: Test verify one behavior per loaded doc (default: one behavior per test, name need "and" = split)?
21	3. ASSERTION QUALITY: Assert observable behavior, not implementation? Specific enough catch regression?
22	4. ISOLATION: Test depend other test output/effects? All mutable state per-test?
23	5. TEST NAME: Name follow team convention per loaded doc (default: describe behavior, not method)? Failure message clear?
24	6. TEST DATA: Complex arrange uses builders/factories? Magic values → named constants? (Inline literals fine for trivial tests.)
25	7. MOCK BOUNDARIES: Mock per loaded doc (default: only at arch boundaries — I/O, external — not internal collab)?
26	8. TEST CODE AS FIRST-CLASS: Structured like production code? Shared constants at top, helpers extracted, no dead code, clear file organization?
27
28	Project-specific checks: if loaded doc contains a validation checklist section, apply those after base checklist.
29
30	## Active Anti-Pattern Scan
31
32	After checklist, scan these. If find, fix before present.
33
34	- [ ] Test-per-Method: One test per method regardless behaviors → One test per scenario, named for behavior
35	- [ ] Assertion Roulette: Multiple unrelated asserts; unclear which broke → Split to one behavior per test
36	- [ ] Shared Mutable State: Pass alone, fail together → Isolate state; per-test setup; no static mutable
37	- [ ] Testing Implementation Details: Break on refactor w/ same behavior; mock call counts → Assert observable behavior, not method calls
38	- [ ] Mystery Guest: Depend external file/db/env var not visible → Inline data or use builders; all preconditions visible
39	- [ ] Slow Tests by Default: Unit suite take minutes; hit db/network/fs → Mock/fake I/O; use in-memory
40	- [ ] Conditional Test Logic: Test have if/loop/try -- test need own tests → Remove logic; use parameterized; let asserts fail natural
41	- [ ] Copy-Paste Tests: Near-identical w/ small changes → Extract shared setup to builders; use parameterized
42
43	## Class-Level Review
44
45	Fire when: (1) completing all tests for a class — new or existing. (2) adding or editing any test in an existing class.
46
47	STOP before present. Per-test checks verify individual quality. This review verifies the test suite covers the class contract.
48
49	### Full review (new class or significant additions)
50
51	1. Behavior inventory — list every public method/behavior in class under test. If class not available, ask user to enumerate.
52	2. Coverage matrix — map each test → behavior it covers. Behaviors with zero tests → blocking. Do not present until user addresses gap or explicitly accepts it.
53	3. Error path check — scan class under test for: explicit throws, conditional error branches, edge guards. For each found: does a test exercise this path? If not → flag by name. Zero-coverage error paths are blocking unless user explicitly accepts.
54	4. Behavioral duplication — compare "then" clauses across all tests. Same observable outcome regardless of structural differences → flag as likely duplication. Name both tests.
55	5. Balance signal — any behavior with tests but none covering a failure or edge case → surface as question, not hard failure: "`deleteUser`

People who liked this also viewed

6 picks

Type

test-quality

165stars12forks

View on GitHub

How to install test-quality?

techygarg/lattice/test-quality

$npx -y skills add techygarg/lattice --skill test-quality

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Test Quality
2
3	## Config Resolution
4
5	Skill support project custom. Order:
6
7	1. Look `.lattice/config.yaml` in repo root
8	2. If find, check `paths.test_quality` for custom doc path
9	3. If custom path exist, read doc & check YAML frontmatter for `mode`:
10	- `mode: override` (or no mode): Custom doc take full control. Use instead default. Must be complete -- is only reference.
11	- `mode: overlay`: Read `./references/defaults.md` first, then apply custom doc on top. Custom sections replace match sections (by heading). New sections add after.
12	4. If no config/path/file, read `./references/defaults.md`
13	5. Language adaptation: If `paths.language_idioms` exist in config, read "Testing Patterns" section and adapt §5 (Test Naming), §4 (Test Isolation), §6 (Test Data Builders) to language test framework idioms. Language idioms take precedence over pseudocode defaults.
14
15	## Self-Validation Checklist
16
17	STOP after gen each test. Check ALL before continue. If fail, fix. If ambiguous (see Ambiguity Signals), flag -- show options & reasoning.
18
19	1. AAA STRUCTURE: arrange, act, assert separate w/ blank lines? Any logic (if/loop/try) in arrange or assert?
20	2. SINGLE BEHAVIOR: Test verify one behavior per loaded doc (default: one behavior per test, name need "and" = split)?
21	3. ASSERTION QUALITY: Assert observable behavior, not implementation? Specific enough catch regression?
22	4. ISOLATION: Test depend other test output/effects? All mutable state per-test?
23	5. TEST NAME: Name follow team convention per loaded doc (default: describe behavior, not method)? Failure message clear?
24	6. TEST DATA: Complex arrange uses builders/factories? Magic values → named constants? (Inline literals fine for trivial tests.)
25	7. MOCK BOUNDARIES: Mock per loaded doc (default: only at arch boundaries — I/O, external — not internal collab)?
26	8. TEST CODE AS FIRST-CLASS: Structured like production code? Shared constants at top, helpers extracted, no dead code, clear file organization?
27
28	Project-specific checks: if loaded doc contains a validation checklist section, apply those after base checklist.
29
30	## Active Anti-Pattern Scan
31
32	After checklist, scan these. If find, fix before present.
33
34	- [ ] Test-per-Method: One test per method regardless behaviors → One test per scenario, named for behavior
35	- [ ] Assertion Roulette: Multiple unrelated asserts; unclear which broke → Split to one behavior per test
36	- [ ] Shared Mutable State: Pass alone, fail together → Isolate state; per-test setup; no static mutable
37	- [ ] Testing Implementation Details: Break on refactor w/ same behavior; mock call counts → Assert observable behavior, not method calls
38	- [ ] Mystery Guest: Depend external file/db/env var not visible → Inline data or use builders; all preconditions visible
39	- [ ] Slow Tests by Default: Unit suite take minutes; hit db/network/fs → Mock/fake I/O; use in-memory
40	- [ ] Conditional Test Logic: Test have if/loop/try -- test need own tests → Remove logic; use parameterized; let asserts fail natural
41	- [ ] Copy-Paste Tests: Near-identical w/ small changes → Extract shared setup to builders; use parameterized
42
43	## Class-Level Review
44
45	Fire when: (1) completing all tests for a class — new or existing. (2) adding or editing any test in an existing class.
46
47	STOP before present. Per-test checks verify individual quality. This review verifies the test suite covers the class contract.
48
49	### Full review (new class or significant additions)
50
51	1. Behavior inventory — list every public method/behavior in class under test. If class not available, ask user to enumerate.
52	2. Coverage matrix — map each test → behavior it covers. Behaviors with zero tests → blocking. Do not present until user addresses gap or explicitly accepts it.
53	3. Error path check — scan class under test for: explicit throws, conditional error branches, edge guards. For each found: does a test exercise this path? If not → flag by name. Zero-coverage error paths are blocking unless user explicitly accepts.
54	4. Behavioral duplication — compare "then" clauses across all tests. Same observable outcome regardless of structural differences → flag as likely duplication. Name both tests.
55	5. Balance signal — any behavior with tests but none covering a failure or edge case → surface as question, not hard failure: "`deleteUser`

People who liked this also viewed

6 picks

Type