Skip to content

chore: improve test-discovery skill with PR docs and TUI E2E guidance #365

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
anandgupta42 merged 1 commit into from
Mar 22, 2026
Merged

chore: improve test-discovery skill with PR docs and TUI E2E guidance #365

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
32 changes: 30 additions & 2 deletions .claude/commands/test-discovery.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -217,7 +217,28 @@ Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>"
git push -u origin HEAD
gh pr create --title "test: [area] — [what's being tested]" --body "$(cat <<'EOF'
### What does this PR do?
Adds tests for [area] discovered by hourly test sweep.

[Write a clear, well-structured description. Do NOT use a one-liner. Include:]

**For each module/file tested, provide:**
- The module name and source file path
- WHY it was untested and WHY it matters (what user-facing risk does this cover?)
- A brief list of the specific scenarios covered (e.g., "push-before-next ordering", "error propagation")

**Example format:**

**1. `AsyncQueue` and `work()` — `src/util/queue.ts`** (10 new tests)

These utilities power streaming result delivery and concurrent task processing. Zero tests existed. New coverage includes:
- Push/next resolution ordering and async iterator correctness
- Concurrency limit enforcement in `work()`
- Error propagation from workers

**2. `State.invalidate` — `src/project/state.ts`** (2 new tests)

This `altimate_change` clears cached state after config changes. Coverage includes:
- Invalidated entry is re-initialized on next access
- No-op on nonexistent key

### Type of change
- [x] New feature (non-breaking change which adds functionality)
Expand All @@ -226,7 +247,12 @@ Adds tests for [area] discovered by hourly test sweep.
N/A — proactive test coverage

### How did you verify your code works?
`bun test test/[path]` — all pass

[List each test file and its pass count, e.g.:]
```
bun test test/util/queue.test.ts # 10 pass
bun test test/project/state.test.ts # 7 pass (5 existing + 2 new)
```

### Checklist
- [x] I have added tests that prove my fix is effective or that my feature works
Expand All @@ -247,3 +273,5 @@ Send `shutdown_request` to the critic. Delete the team.
6. **Critic must approve.** Don't commit tests the critic rejected.
7. **Check existing tests first.** Run `grep -r "describe.*[feature]" packages/opencode/test/` before writing.
8. **Branch protection.** Always use a feature branch + PR. Never push to main.
9. **TUI impact check.** Whenever your tests touch code that feeds into the TUI (session state, config, skills, tools, MCP, provider changes), check whether the TUI could be affected. If so, add or extend E2E tests that exercise the TUI path — e.g., verifying that dialog rendering, skill listing, or config display still work after the change. The TUI is the primary user interface; regressions there are high-visibility. Look at existing TUI tests in `packages/opencode/test/config/tui.test.ts` for patterns.
10. **PR descriptions must be well-documented.** Never submit a one-liner PR body. Each PR must clearly explain what modules were tested, why they were untested, what user-facing risk the new tests mitigate, and the specific scenarios covered. See the PR template in Phase 5 for the expected format.
Loading