gds-test-review
Review test quality and coverage. Use when the user says "test review" or "review tests"
- License 许可
- MIT
- 最近更新
- 2026-07-19
- Stars
- ★ 1
- Forks
- 0
01 前言 Front Matter
- name
- gds-test-review
- description
- Review test quality and coverage. Use when the user says "test review" or "review tests"
02 资源文件 3
- 参考文档checklist.md1.5 KB
- 其他customize.toml1.6 KB
- 参考文档test-review-template.md5.8 KB
03 SKILL.md 正文
Test Review
Workflow ID: gds-test-review
Version: 1.0 (BMad v6)
Conventions
- Bare paths (e.g.
template.md) resolve from the skill root. {skill-root}resolves to this skill's installed directory (wherecustomize.tomllives).{project-root}-prefixed paths resolve from the project working directory.{skill-name}resolves to the skill directory's basename.
On Activation
Step 1: Resolve the Workflow Block
Run: python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow
If the script fails, resolve the workflow block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
{skill-root}/customize.toml— defaults{project-root}/_bmad/custom/{skill-name}.toml— team overrides{project-root}/_bmad/custom/{skill-name}.user.toml— personal overrides
Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by code or id replace matching entries and append new entries, and all other arrays append.
Step 2: Execute Prepend Steps
Execute each entry in {workflow.activation_steps_prepend} in order before proceeding.
Step 3: Load Persistent Facts
Treat every entry in {workflow.persistent_facts} as foundational context you carry for the rest of the workflow run. Entries prefixed file: are paths or globs under {project-root} — load the referenced contents as facts. All other entries are facts verbatim.
Step 4: Load Config
Load config from {project-root}/_bmad/gds/config.yaml and resolve:
user_namecommunication_languageoutput_folder
Step 5: Greet the User
Greet {user_name}, speaking in {communication_language}.
Step 6: Execute Append Steps
Execute each entry in {workflow.activation_steps_append} in order.
Activation is complete. Begin the workflow below.
Goal
Review existing test suite quality, identify coverage gaps, and recommend improvements. Regular test review prevents test rot and maintains test value over time.
Role
You are a Game QA Lead with expertise in test suite analysis. You evaluate test quality against industry best practices, identify systemic gaps in coverage, and produce actionable recommendations prioritized by risk and player impact.
WORKFLOW ARCHITECTURE
This workflow analyzes the existing test suite and produces a comprehensive review report with prioritized action items.
Primary Output: {output_folder}/test-review-report.md
Supporting Components:
- Validation:
{installed_path}/checklist.md - Template:
{installed_path}/test-review-template.md
Knowledge Base References:
knowledge/regression-testing.mdknowledge/test-priorities.md
Load and resolve configuration from {module_config}:
output_folder: {from config}
user_name: {from config}
communication_language: {from config}
document_output_language: {from config}
game_dev_experience: {from config}
date: {system-generated}
Resolve workflow variables:
review_scope: "full" # full | targeted | quick
game_engine: "auto" # auto | unity | unreal | godot
Search the project for existing test files and results before proceeding.
EXECUTION
Preflight Requirements
Verify before proceeding:
- Test suite exists (some tests to review)
- Access to test execution results
- Understanding of game features
Step 1: Gather Test Suite Metrics
Actions
-
Count Tests by Type
Type Count Pass Rate Avg Duration Unit Integration Play Mode/Functional Performance Total -
Analyze Test Results
- Recent pass rate (last 10 runs)
- Flaky tests (inconsistent results)
- Slow tests (> 30s individual)
- Disabled/skipped tests
-
Map Coverage
- Features with tests
- Features without tests
- Critical paths covered
Step 2: Assess Test Quality
Quality Criteria
For each test, evaluate:
| Criterion | Good | Bad |
|---|---|---|
| Deterministic | Same input = same result | Flaky, timing-dependent |
| Isolated | No shared state | Tests affect each other |
| Fast | < 5s (unit), < 30s (integration) | Minutes per test |
| Readable | Clear intent, good names | Cryptic, no comments |
| Maintained | Up-to-date, passing | Disabled, stale |
| Valuable | Tests real behavior | Tests implementation details |
Anti-Pattern Detection
Look for these common issues:
Hard-coded waits:
await Task.Delay(5000); // Bad
await WaitUntil(() => cond); // Good
Shared test state:
static bool wasSetup; // Dangerous
[SetUp] void Setup() { ... } // Good
Testing private implementation:
var result = obj.GetPrivateField(); // Bad
var result = obj.PublicBehavior(); // Good
Missing cleanup:
var go = Instantiate(prefab); // Leaks
var go = Instantiate(prefab);
AddCleanup(() => Destroy(go)); // Good
Assertion-free tests:
void Test() { DoSomething(); } // What does it test?
void Test() { DoSomething(); Assert.That(...); } // Clear
Step 3: Identify Coverage Gaps
Critical Areas to Verify
| Area | P0 Coverage | P1 Coverage | Gap? |
|---|---|---|---|
| Core Loop | |||
| Save/Load | |||
| Progression | |||
| Combat | |||
| UI/Menus | |||
| Multiplayer | |||
| Platform Cert |
Gap Identification Process
- List all game features
- Check if each feature has tests
- Assess test depth (happy path only vs edge cases)
- Prioritize gaps by risk
Step 4: Review Test Infrastructure
Framework Health
- [ ] Tests run in CI
- [ ] Results are visible to team
- [ ] Failures block deployments
- [ ] Test data is versioned
- [ ] Fixtures are reusable
- [ ] Helpers reduce duplication
Maintenance Burden
- How often do tests need updates?
- Are updates proportional to code changes?
- Do refactors break tests unnecessarily?
Step 5: Generate Recommendations
Priority Matrix
| Finding | Severity | Effort | Recommendation |
|---|---|---|---|
| {finding} | {High/Med/Low} | {High/Med/Low} | {action} |
Common Recommendations
For Flaky Tests:
- Replace
Thread.Sleepwith explicit waits - Add proper synchronization
- Isolate test state
For Slow Tests:
- Move to nightly builds
- Optimize test setup
- Mock expensive dependencies
For Coverage Gaps:
- Prioritize P0/P1 features
- Add smoke tests first
- Use test-design workflow
For Maintenance Issues:
- Refactor common patterns
- Create test utilities
- Improve documentation
Step 6: Generate Test Review Report
Write {output_folder}/test-review-report.md using the test-review-template.md structure:
# Test Review Report: {Project Name}
## Executive Summary
- Overall health: {Good/Needs Work/Critical}
- Key findings: {3-5 bullet points}
- Recommended actions: {prioritized list}
## Metrics
### Test Suite Statistics
[Tables from Step 1]
### Recent History
[Pass rates, trends]
## Quality Assessment
### Strengths
- {What's working well}
### Issues Found
| Issue | Severity | Tests Affected | Fix |
| ----- | -------- | -------------- | --- |
| | | | |
## Coverage Analysis
### Current Coverage
[Feature coverage table]
### Critical Gaps
[Prioritized list of missing coverage]
## Recommendations
### Immediate (This Sprint)
1. {Fix critical issues}
### Short-term (This Milestone)
1. {Address major gaps}
### Long-term (Ongoing)
1. {Improve infrastructure}
## Appendix
### Flaky Tests
[List with failure patterns]
### Slow Tests
[List with durations]
### Disabled Tests
[List with reasons]
Review Frequency
| Review Type | Frequency | Scope | Owner |
|---|---|---|---|
| Quick Check | Weekly | Pass rates, flaky tests | QA |
| Full Review | Monthly | Coverage, quality | Tech Lead |
| Deep Dive | Quarterly | Infrastructure, strategy | Team |
Deliverables
- Test Review Report — Comprehensive analysis
- Action Items — Prioritized improvements
- Coverage Matrix — Visual gap identification
- Technical Debt List — Tests needing refactor
Validation
Refer to checklist.md for validation criteria.
On Complete
Run: python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow.on_complete
If the resolved workflow.on_complete is non-empty, follow it as the final terminal instruction before exiting.
04 同仓库更多 Skills
gds-correct-course
Manage significant changes during sprint execution. Use when the user says "correct course" or "propose sprint change"
gds-code-review
Review code changes adversarially using parallel review layers (Blind Hunter, Edge Case Hunter, Acceptance Auditor) with structured triage into actionable categories. Use when the user says "run code review" or "review this code"
gds-check-implementation-readiness
Verify GDD, UX, Architecture, and Epics alignment before production. Use when the user says "check readiness" or "implementation readiness"
gds-brainstorm-game
Facilitate game brainstorming sessions with game-specific techniques. Use when the user says "brainstorm game" or "game ideas"
gds-agent-tech-writer
Technical documentation specialist and knowledge curator for game projects. Use when the user asks to talk to Paige or requests the Technical Writer.
gds-agent-game-solo-dev
Elite indie game developer for rapid prototyping and solo quick-flow development. Use when the user asks to talk to Indie or requests the Game Solo Dev.