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)

Más de este repositorio

mismo repositorio

angular-patterns

Wayne0607/ReviewForge

Angular 代码审查规则。当审查 Angular 项目的 .ts 文件（组件/服务/Directive）时套用。检查 DI、RxJS 订阅管理、Signals、Change Detection、模板安全（[innerHTML] XSS）。

2026-07-022

code-quality

Wayne0607/ReviewForge

跨语言通用代码质量规则。当没有匹配的语言特定 skill 时作为 fallback 使用。适用于函数复杂度、命名规范、死代码、魔法数字。

2026-07-022

go-best-practices

Wayne0607/ReviewForge

Go 代码审查规则。当审查 .go 文件时套用。检查错误处理、goroutine 生命周期、接口设计、命名惯例、defer 使用。

2026-07-022

java-best-practices

Wayne0607/ReviewForge

Java 代码审查规则。当审查 .java 文件时套用。检查异常处理、资源管理（try-with-resources）、Optional 使用、Stream API、安全漏洞。

2026-07-022

python-best-practices

Wayne0607/ReviewForge

Python 代码审查规则。当审查 .py 文件时套用。检查类型注解、异常处理、命名规范、函数复杂度、安全漏洞（eval/exec/pickle/yaml.load/os.system）。

2026-07-022

react-patterns

Wayne0607/ReviewForge

React/Next.js 代码审查规则。当审查 JSX/TSX 文件（React 项目）时套用。检查组件设计、Hooks 使用、状态管理、性能、安全（XSS）。

2026-07-022

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)