testing-rules

name	testing_rules
description	跨语言测试质量审查规则。当 diff 包含测试文件或新增公共 API 时需要对应测试时套用。检查覆盖率、边界条件、mock 使用、测试命名。
category	methodology
reviewer_type	testing
languages	[]

Testing Rules Review (Universal)

When to Apply

• Diff 中包含测试文件（test_*.py, *_test.go, *Test.java, *.spec.ts, *.test.ts）
• 新增了公共函数/类/方法但没有对应测试
• 修改了业务逻辑但未更新测试

When NOT to Apply

• 纯重构 PR（行为不变的重命名/提取方法）→ 不需要新增测试
• 文档变更 → 不需要测试
• 配置文件修改 → 除非配置项改变行为
• 依赖版本升级 → 不需要自己写测试（除非有兼容性问题）
• 已弃用代码的删除 → 不需要补充测试
• 样板/脚手架代码（简单的 getter/setter/CRUD 代理）→ 可选，不强制
• 紧急热修复 → 回归测试足够，不强求新测试

Key Areas

Test Coverage

• New public functions/methods should have corresponding tests
• Critical paths (auth, payment, data mutation) must have tests covering happy path + edge cases
• Bug fixes must include a regression test that fails before the fix and passes after
• Don't flag: private/internal helpers, simple delegation methods, getters/setters

Test Boundaries

• Test boundary conditions: empty input, null/None/nil, max values, zero values, negative numbers
• Test error paths: what happens when an external dependency fails, times out, or returns unexpected data
• Test concurrency edge cases when applicable: race conditions, deadlocks, ordering assumptions

Mocking

• Don't mock what you don't own — wrap third-party libraries in your own interface
• Over-mocking leads to tests that pass while the real integration is broken
• Prefer real in-memory implementations (fakes) over mocks for databases, caches, queues
• Mock at the architectural boundary, not every internal dependency

Test Quality

• Test names must describe the scenario and expected outcome
• Each test should test one behavior; avoid multi-step E2E scenarios in a single test
• Avoid logic in tests: no if/else, no loops with dynamic assertions — tests should be linear
• Flaky tests are worse than no tests — they erode trust in the suite
• Assertions must be specific: assertEquals(expected, actual) > assertTrue(actual.contains(x))

Test Organization

• Structure: Arrange → Act → Assert (given → when → then)
• Shared setup goes in fixtures/setUp/beforeEach, not duplicated in every test
• Test files should mirror source structure

Validation Criteria

True Positive: The test gap means a bug could reach production undetected. Confidence > 0.6.

False Positive:

• The function being called is a private helper tested indirectly via public API
• The class is a simple DTO/value object with only getters/setters
• The method is a thin wrapper around a well-tested library function
• The code is in a prototype/experimental module
• The test coverage gap is for trivial glue code (controller → service → repository wiring)
• It's an integration test covering the happy path only (this is often intentional)