docs(test): add claude test command

[Manabu-GT]

Summary by CodeRabbit

• Documentation
  • Added a detailed guide for generating focused Kotlin unit tests, covering testing patterns, naming and structure conventions, usage examples for targeting files or changed modules, rules for when to skip trivial code, and steps to run coverage checks across modules.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Warning

Rate limit exceeded

@Manabu-GT has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 22 minutes and 6 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

Note

Other AI code review bot(s) detected

CodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review.

Walkthrough

Added a new Markdown guide at \.claude/commands/test.md that prescribes a process and rules for generating focused Kotlin unit tests, including usage examples, testing patterns, and Gradle coverage commands.

Changes

Cohort / File(s)	Summary
Test generation guide \.claude/commands/test.md	New guide describing steps to read docs/TESTING.md, analyze Kotlin files, detect component types, generate tests following project patterns, usage examples (single file or all changed files), test generation rules, and Gradle coverage commands for all/single modules.

Sequence Diagram(s)

(omitted — documentation-only addition; no control-flow changes meeting diagram criteria)

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Possibly related PRs

• [docs] refactors the monolithic AGENTS.md file into a more maintainable, focused structure #131 — Updates/adds docs/TESTING.md referenced by the new test generation guide.

Poem

🐰 I hop through docs with a testing cheer,
Writing specs so each case is clear,
Kotlin tests lined up in a row,
Coverage blooms where the assertions go,
Hop, run, and watch your green bars grow! ✨

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: adding a new Claude test command documentation file (.claude/commands/test.md). It is concise, specific, and clearly summarizes the primary purpose of the changeset.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[claude]

Claude finished @Manabu-GT's task in 1m 15s —— View job

---

PR Review: Add Claude Test Command

Tasks

• Read the new command file
• Review project testing documentation
• Analyze command structure and content
• Provide detailed feedback

---

Summary

This PR adds a new Claude command (/test) to generate unit tests for Kotlin files following project conventions. The command file is well-structured and comprehensive, with clear documentation that aligns with the project's testing standards.

Strengths

1. Excellent documentation alignment - The command directly references and follows docs/TESTING.md, ensuring consistency with established testing patterns
2. Clear process flow - The 4-step process (read guidelines → analyze code → detect type → generate tests) is logical and thorough
3. Good usage examples - Both single-file and --changed flag examples are helpful
4. Comprehensive quick reference - The quick reference section provides useful pointers to specific testing patterns
5. Practical coverage commands - Including Gradle commands for running Jacoco reports is helpful

Observations & Suggestions

1. Command Scope and Behavior

The command states it will "Generate unit tests" but doesn't specify important behavioral details:

• Where will the tests be written? - Will it create new test files or append to existing ones?
• Overwrite behavior - What happens if a test file already exists?
• Dry-run option - Should there be a --dry-run flag to preview what would be generated?

Recommendation: Consider adding a "Behavior" section clarifying:

## Behavior

- Creates new test files in `src/test/kotlin/` mirroring the source path
- If a test file already exists, prompts before modifying
- Skips files that already have test coverage (unless `--force` is used)

2. Tech Stack Specification

Line 30 mentions "JUnit 4, Truth assertions, MockK, Turbine, Robolectric" which correctly matches docs/TESTING.md:3-10. However, this is mentioned in the "Test Generation Rules" section rather than at the top where it would be more discoverable.

Suggestion: Consider moving tech stack info to the top-level "Process" section or creating a dedicated "Tech Stack" section for quick reference.

3. The --changed Flag

Lines 46-48 specify comparing against main, but the repository structure shows:

• The PR is targeting a branch called main (based on PR context)
• Git status shows current branch is chore/commands with no configured main branch

Question: Should the comparison be configurable or hardcoded to main? Some projects use master, develop, or other branch names.

Suggestion:

## When using `--changed`

- Compare current branch against base branch (default: `main`)
- Use `--base <branch>` to specify a different base branch
- Only process `.kt` files (exclude test files)
- Generate tests for each file that doesn't have corresponding test coverage

4. "Skip trivial code" Rule

Line 34 states: "Skip trivial code: Don't test simple getters, data classes, or framework behavior"

This is good guidance, but the command doesn't explain how it determines what's trivial. This could lead to inconsistent behavior.

Suggestion: Add examples of what will/won't be tested:

## What Gets Tested

**Will generate tests for:**
- ViewModels with state management logic
- Repository classes with data transformations
- Utility functions with business logic
- Custom data structures (e.g., `EvictingQueue`)

**Will skip:**
- Data classes with only properties
- Simple delegation patterns
- One-line getters/setters

5. Missing Error Handling Guidance

The command doesn't specify what happens when:

• The target file doesn't exist
• The file has no testable code
• Dependencies can't be determined
• The module doesn't have a test source set

Recommendation: Add an "Error Handling" or "Troubleshooting" section.

Code Quality Assessment

Structure: ✅ Well-organized with clear sections
Clarity: ✅ Instructions are understandable
Completeness: ⚠️ Missing behavioral specifications (see above)
Alignment: ✅ Correctly references and follows docs/TESTING.md
Security: ✅ N/A - documentation only
Performance: ✅ N/A - documentation only

Potential Issues

1. Line 29: "Read existing tests" - This assumes tests exist. Need fallback behavior for modules without existing tests.

2. Line 48: "exclude test files" - How are test files identified? By path (**/test/**) or filename pattern (*Test.kt)?

3. Coverage reports path (lines 61-62) - These paths are correct for standard Gradle projects, but might want to note that paths assume default Gradle build directory structure.

Recommendations

1. Add behavioral specifications for test file creation/modification
2. Clarify detection logic for what code is "testable" vs "trivial"
3. Add error handling section for common failure scenarios
4. Consider adding flags:
   • --force to regenerate existing tests
   • --base <branch> for custom base branch comparison
   • --dry-run to preview what would be generated

Verdict

This is a solid first version of the test command. The documentation is comprehensive and aligns well with project standards. The suggestions above would make the command more predictable and easier to use, but the current version is already functional and useful.

Recommendation: Approve with suggested enhancements to be addressed in follow-up PRs.

---

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In @.claude/commands/test.md:
- Around line 22-25: The fenced code block showing the test commands for
MemoryDataSource.kt lacks a language identifier; update the opening fence from
``` to include a language (e.g., ```bash) so the block becomes ```bash and keep
the existing lines "/test
debugoverlay-core/src/main/kotlin/com/ms/square/debugoverlay/internal/data/source/MemoryDataSource.kt"
and "/test --changed" unchanged to enable proper syntax highlighting and
consistency.

[claude]

Claude finished @Manabu-GT's task in 1m 53s —— View job

---

PR Review: Claude Test Command Documentation

Tasks

• Read project testing guidelines (docs/TESTING.md)
• Review command structure and frontmatter
• Analyze command documentation completeness
• Check alignment with project standards
• Provide detailed feedback

---

Summary

This PR adds comprehensive documentation for a new /test command that generates unit tests for Kotlin files. The command structure is well-organized and correctly references project testing standards from docs/TESTING.md.

Overall Assessment

Strengths:

• ✅ Excellent alignment with docs/TESTING.md - correctly references tech stack (JUnit 4, Truth, MockK, Turbine, Robolectric)
• ✅ Clear 4-step process flow (read guidelines → analyze code → detect type → generate tests)
• ✅ Good usage examples with both single-file and --changed flag options
• ✅ Helpful quick reference section pointing to specific testing patterns
• ✅ Practical coverage commands included (Jacoco reports)
• ✅ Proper frontmatter with name and description

Areas for improvement:

• ⚠️ Missing behavioral specifications (file creation, overwrite behavior, scope)
• ⚠️ Ambiguous filtering logic for --changed flag
• ⚠️ "Skip trivial code" rule lacks clear criteria
• ⚠️ Assumes existing tests exist (no fallback strategy documented)
• 🐛 Minor: Code block at line 22 missing bash language identifier (flagged by CodeRabbit)

Detailed Findings

I've left 5 inline comments on specific sections that could be enhanced:

1. Line 22: Missing bash language identifier in code block
2. Line 29: "Read existing tests" assumes tests exist - needs fallback strategy
3. Line 34: "Skip trivial code" lacks clear criteria for what's considered trivial
4. Lines 28-35: Missing behavioral specifications (file creation, overwrite, scope)
5. Lines 44-48: --changed flag behavior needs clarification (base branch, file detection, coverage determination)

Code Quality

Aspect	Rating	Notes
Structure	✅ Good	Well-organized sections with clear hierarchy
Clarity	⚠️ Fair	Main instructions clear, but edge cases undefined
Completeness	⚠️ Fair	Missing behavioral specs and error handling
Alignment	✅ Excellent	Correctly references and follows docs/TESTING.md
Usability	⚠️ Fair	Core usage clear, but ambiguities may cause confusion

Recommendations

Priority 1 (Should address):

1. Add a "Behavior" section clarifying file creation/modification behavior
2. Clarify --changed flag filtering logic (base branch, test file detection)
3. Define clear criteria for what qualifies as "trivial code" to skip

Priority 2 (Nice to have):
4. Add fallback strategy when no existing tests exist in a module
5. Consider adding optional flags (--force, --base <branch>, --dry-run)
6. Add an "Error Handling" or "Troubleshooting" section

Priority 3 (Future enhancement):
7. Add examples of what will/won't be tested
8. Specify how dependencies are determined for mocking decisions

Alignment with Project Standards

The command correctly follows the project's testing philosophy from docs/TESTING.md:

• ✅ Uses correct tech stack (JUnit 4, Truth, MockK, Turbine, Robolectric) - lines 3-10 in TESTING.md
• ✅ References DO/DON'T Mock guidance - lines 24-40 in TESTING.md
• ✅ Specifies backtick naming for unit tests - lines 79-83 in TESTING.md
• ✅ Points to Flow testing patterns - lines 134-142 in TESTING.md
• ✅ References test doubles guidance - lines 179-201 in TESTING.md

Verdict

This is a solid foundation for the test command. The core documentation is well-structured and aligns with project standards. The inline comments I've left highlight specific areas where additional clarity would make the command more predictable and easier to use.

Recommendation: The current version is functional and provides good guidance. The suggested enhancements would improve clarity and reduce ambiguity, but can be addressed in follow-up iterations based on actual usage patterns.

---

[claude]

Clarification needed: "Skip trivial code" logic

This rule states to skip "simple getters, data classes, or framework behavior", but doesn't explain how the command determines what qualifies as "trivial". This could lead to inconsistent behavior.

Suggestion: Add examples of what will/won't be tested:

6. **Test coverage scope**:
   - ✅ Generate tests for: ViewModels with state logic, Repositories with data transformations, utility functions with business logic, custom data structures (e.g., `EvictingQueue`)
   - ❌ Skip: Data classes with only properties, simple delegation patterns, one-line getters/setters, pure pass-through functions

This aligns with the "What to Test" section in docs/TESTING.md:24-40.

[claude]

Claude finished @Manabu-GT's task in 52s —— View job

---

PR Review: Claude Test Command Documentation

Tasks

• Read the current version of the test command file
• Review project testing documentation for alignment
• Analyze command structure and completeness
• Check if previous review feedback has been addressed
• Provide detailed review feedback

---

Summary

This PR adds comprehensive documentation for a new /test command that generates unit tests for Kotlin files following project conventions. The author has done an excellent job incorporating all feedback from previous reviews.

What Changed Since Last Review

The author has addressed all major feedback points from previous Claude reviews:

1. ✅ Added Behavior section (lines 15-21) - Now clearly specifies file creation, overwrite prompting, scope, error handling, and existing coverage detection
2. ✅ Clarified test coverage scope (lines 42-44) - Provides concrete examples of what will/won't be tested with clear ✅/❌ markers
3. ✅ Enhanced --changed flag documentation (lines 54-59) - Specifies base branch override, path exclusions, test file detection pattern, and force flag behavior
4. ✅ Added fallback strategy for missing tests (line 37) - Documents behavior when no existing tests exist in the module
5. ✅ Added bash language identifier (line 30) - Fixes the markdown linting issue flagged by CodeRabbit

Verification Against Project Standards

The command documentation correctly aligns with docs/TESTING.md:

Aspect	Test Command Reference	TESTING.md Reference	Status
Tech stack	Lines 38: JUnit 4, Truth, MockK, Turbine, Robolectric	Lines 3-10	✅ Match
Test naming	Line 41: Backticks for test names	Lines 79-83	✅ Match
DO/DON'T Mock	Line 39: References guidance	Lines 24-40, 179-201	✅ Match
Test coverage scope	Lines 42-44: What to test/skip	Lines 24-40	✅ Match
Flow testing patterns	Line 49: References section	Lines 134-142	✅ Match
Virtual time testing	Line 50: References section	Lines 145-177	✅ Match
Robolectric usage	Line 52: References section	Lines 202-204	✅ Match

Final Assessment

Structure: ✅ Excellent - Well-organized with clear sections
Clarity: ✅ Excellent - All ambiguities from previous reviews resolved
Completeness: ✅ Excellent - All behavioral specifications documented
Alignment: ✅ Excellent - Correctly references and follows docs/TESTING.md
Usability: ✅ Excellent - Command behavior is predictable and well-documented

Minor Observations

The documentation is now comprehensive and production-ready. A few observations for potential future enhancements (not blocking for this PR):

1. Example output: Could optionally show what generated test output looks like
2. Error messages: Could document common error messages and how to resolve them
3. Performance note: For large codebases, could mention expected runtime with --changed

These are minor "nice-to-haves" that could be added based on actual usage patterns after the command is deployed.

Recommendation

✅ APPROVE - This PR is ready to merge. The author has thoroughly addressed all previous feedback, and the documentation is comprehensive, clear, and well-aligned with project standards.

---