code-testing-quality

星标0

分支0

更新时间2026年2月24日 06:45

Unit testing principles, test structure patterns, test doubles strategy, naming conventions, testing antipatterns, and coverage guidance. Use when writing tests, reviewing test quality, evaluating test coverage, choosing test doubles, fixing flaky tests, or assessing test structure during cook and serve phases. Enhances taster agent during TDD cycle.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

来源

smileynet

smileynet/code-spice

打开 GitHub 仓库查看创作者相关仓库

下载

Code Testing Quality

Testing Quality Checklist

Three Properties of Good Tests

Property	Meaning	Violation Signal
Isolated	No test affects another; runs alone or in any order	Tests pass individually but fail together
Repeatable	Same result every time, on any machine	"Works on my machine," intermittent failures
Clear	Failure message pinpoints the problem	Must read test code to understand what broke

Test Doubles Decision Table

Situation	Recommended Double	Why
External API or network call	Stub	Isolation from external non-determinism
Database in integration test	Fake (in-memory DB)	Realistic behavior, fast execution
Verifying a notification was sent	Mock	The side effect is the behavior
Complex collaborator with state	Fake	Maintains realistic internal consistency
Legacy code you can't refactor yet	Spy	Observe without modifying production code
Internal collaborator (same module)	Real object	Prefer real dependencies for internal code

Rule of thumb: Mock at architectural boundaries (network, database, filesystem, external services). Use real objects for internal collaborators.

Test Naming Patterns

Pattern	Example	Best For
`method_scenario_expectedResult`	`withdraw_insufficientFunds_throwsException`	Unit tests with clear method focus
`should [outcome] when [condition]`	`should reject withdrawal when funds insufficient`	Behavior-focused tests
`given_when_then`	`givenInsufficientFunds_whenWithdraw_thenThrows`	BDD-style tests

The failure message test: When a test fails, can you understand the bug from the test name alone? If yes, the name is good.

Testing Antipatterns

Antipattern	Symptom	Severity	Fix
Flaky tests	Pass/fail without code changes	Critical	Remove non-determinism: no sleeps, no real clocks, no shared state
Test interdependence	Tests pass alone, fail together	Critical	Each test creates/destroys its own data
Testing implementation	Refactoring breaks tests	Major	Assert on outputs and side effects, not internal method calls
Logic in tests	Conditionals, loops, try-catch in test code	Major	Tests should be straight-line code
Slow tests	Suite takes minutes, developers skip it	Major	Isolate from I/O; use fakes; parallelize
Obscure tests	Must read full test to understand intent	Moderate	Descriptive names, visible AAA structure
Fragile assertions	Tests break on irrelevant output changes	Moderate	Assert on relevant fields only
Liar tests	Tests that always pass regardless of behavior	Critical	Verify tests fail when behavior is wrong (mutation testing)
Giant arrange	50 lines of setup, 1 line of act	Moderate	Use builders/factories; consider whether unit is too large
Snapshot abuse	Blindly approving snapshot updates	Moderate	Prefer explicit assertions for logic

Coverage Guidance

Coverage Target	Context	Rationale
>80% of critical paths	Most projects	Balances thoroughness with diminishing returns
>90%	Safety-critical, financial	Higher stakes justify investment
60-70%	Early-stage, prototypes	Focus on core behavior first

Beyond line coverage: Branch coverage is more meaningful. Mutation testing reveals "liar tests" — tests that run code but don't verify it. A high mutation score (>80%) indicates tests that actually catch defects.

"Why Is This Test Bad?"

Symptom	Likely Antipattern	Action
Test breaks after refactoring (behavior unchanged)	Testing implementation	Assert on outputs, not method calls
Test fails intermittently	Flaky test	Remove non-determinism (time, state, I/O)
Can't understand failure from test name	Obscure test	Rename to describe scenario + expected outcome
50+ lines of setup	Giant arrange	Use builders; consider splitting the unit
Tests pass but bugs ship	Liar test / weak assertions	Add mutation testing
Test suite takes >5 minutes	Slow tests	Replace I/O with fakes; parallelize

Checklists

Before Writing a Test

Identify the specific behavior to verify (not the implementation)
Determine test level: unit, integration, or E2E
Choose test double strategy (prefer real objects; mock at boundaries)
Plan for edge cases and error paths

Test Quality Self-Review

Each test has one clear reason to fail
Test names describe scenario and expected outcome
No shared mutable state between tests
No non-determinism (time, randomness, network, filesystem)
Assertions verify behavior, not implementation
Test fails when the behavior it guards is broken

同仓库更多 Skills

同仓库

code-antipatterns

smileynet/code-spice

Antipattern catalog with categorized patterns, symptoms, examples, and fixes. Use when reviewing code for quality issues, detecting bad patterns during plan-audit or scope, evaluating whether a pattern is an antipattern or acceptable tradeoff, or fixing existing code smells. Covers surprise, misuse, complexity, and premature antipattern categories with severity classification.

2026-02-240

code-naming

smileynet/code-spice

Naming decisions for variables, functions, classes, constants, and APIs. Use when choosing names, reviewing naming quality, refactoring unclear names, or establishing naming conventions. Covers descriptive naming, naming as documentation, language-specific conventions, and common naming antipatterns.

2026-02-240

code-plan-audit

smileynet/code-spice

Plan quality auditing with completeness scorecard, antipattern risk detection, and readiness checks. Use when auditing implementation plans, evaluating plan completeness, checking error handling strategy, assessing naming and readability pre-checks, reviewing testing strategy, evaluating tradeoff documentation, or running plan-audit on a software project. Covers the 10-point completeness scorecard, code quality pre-checks, antipattern risk assessment, and build-readiness decision.

2026-02-240

code-pruning

smileynet/code-spice

Dead code detection strategies, safe removal processes, dependency pruning, and bloat metrics for systematically reducing codebase dead weight. Use when evaluating codebase health during architecture-audit, performing cleanup during cook, reviewing unused dependencies, removing commented-out code, or measuring code bloat.

2026-02-240

code-quality-foundations

smileynet/code-spice

Code quality pillars, goals, abstraction layers, and tradeoff thinking. Use when evaluating code quality, setting quality goals, choosing abstraction levels, making design tradeoffs, or auditing code against quality pillars. Covers readability, modularity, testability, reusability, and the principle of least astonishment.

2026-02-240

code-readability

smileynet/code-spice

Code readability patterns covering comments, function decomposition, nesting, naming conventions, and code structure. Use when evaluating whether code is easy to understand, deciding when and how to write comments, decomposing functions, reducing nesting depth, improving code structure, or reviewing code for readability. Covers comment strategy, function length, abstraction level mixing, nesting reduction, anonymous function readability, and making bad code visually obvious.

2026-02-240

name	code-testing-quality
description	Unit testing principles, test structure patterns, test doubles strategy, naming conventions, testing antipatterns, and coverage guidance. Use when writing tests, reviewing test quality, evaluating test coverage, choosing test doubles, fixing flaky tests, or assessing test structure during cook and serve phases. Enhances taster agent during TDD cycle.