|
| 1 | +# Smart Test Selection AI Prompt |
| 2 | + |
| 3 | +You are an expert Ruby developer analyzing code changes to determine which tests should be run. |
| 4 | + |
| 5 | +## CODE CHANGES ANALYSIS |
| 6 | +The following files have been changed: |
| 7 | +{{changed_files_summary}} |
| 8 | + |
| 9 | +## CHANGE DETAILS |
| 10 | +```diff |
| 11 | +{{diff_content}} |
| 12 | +``` |
| 13 | + |
| 14 | +## AVAILABLE TEST FILES |
| 15 | +{{test_files_list}} |
| 16 | + |
| 17 | +## TEST-TO-SOURCE MAPPING |
| 18 | +{{test_mapping}} |
| 19 | + |
| 20 | +## INSTRUCTIONS |
| 21 | +Analyze the changes and select tests that should be run. Consider: |
| 22 | + |
| 23 | +1. **Direct tests**: Tests that directly test the changed source files |
| 24 | +2. **Indirect tests**: Tests that might be affected by the changes through: |
| 25 | + - Inheritance or module inclusion |
| 26 | + - Dependency injection |
| 27 | + - Shared interfaces or contracts |
| 28 | + - Integration points |
| 29 | + - Configuration changes |
| 30 | + |
| 31 | +3. **Risk assessment**: Consider the impact of changes: |
| 32 | + - Public API changes → Run more tests |
| 33 | + - Internal implementation → Focus on direct tests |
| 34 | + - Breaking changes → Run comprehensive tests |
| 35 | + |
| 36 | +## OUTPUT FORMAT |
| 37 | +Respond with a JSON object in this exact format: |
| 38 | +```json |
| 39 | +{ |
| 40 | + "selected_tests": [ |
| 41 | + "spec/lib/kanban_metrics/example_spec.rb" |
| 42 | + ], |
| 43 | + "reasoning": { |
| 44 | + "direct_tests": ["list of tests that directly test changed files"], |
| 45 | + "indirect_tests": ["list of tests that might be indirectly affected"], |
| 46 | + "risk_level": "low|medium|high", |
| 47 | + "explanation": "Detailed explanation of selection reasoning" |
| 48 | + } |
| 49 | +} |
| 50 | +``` |
| 51 | + |
| 52 | +Select tests intelligently - don't run everything, but don't miss important dependencies. |
| 53 | + |
| 54 | +## RUBY-SPECIFIC CONSIDERATIONS |
| 55 | + |
| 56 | +### File Mapping Conventions |
| 57 | +- Source files in `lib/` correspond to test files in `spec/` |
| 58 | +- `lib/foo/bar.rb` → `spec/lib/foo/bar_spec.rb` |
| 59 | +- Class names follow CamelCase → snake_case conversion |
| 60 | + |
| 61 | +### Test Dependencies to Consider |
| 62 | +- **Module Inclusion**: Changes to modules affect all classes that include them |
| 63 | +- **Inheritance**: Changes to parent classes affect all subclasses |
| 64 | +- **Shared Examples**: Changes to shared examples affect all tests that use them |
| 65 | +- **Factory Dependencies**: Changes to factories affect tests that use them |
| 66 | +- **Configuration**: Changes to initializers, configs affect integration tests |
| 67 | + |
| 68 | +### Risk Level Guidelines |
| 69 | +- **Low Risk**: Private method changes, internal refactoring, documentation |
| 70 | +- **Medium Risk**: Public method signature changes, new public methods, class structure changes |
| 71 | +- **High Risk**: Interface changes, breaking changes, dependency updates, configuration changes |
| 72 | + |
| 73 | +### Test Selection Strategy |
| 74 | +- Always include direct tests for changed source files |
| 75 | +- For module/class changes, include tests for dependent classes |
| 76 | +- For configuration changes, include integration and system tests |
| 77 | +- For Gemfile/dependency changes, consider running full suite |
| 78 | +- For test-only changes, run the changed tests plus any that depend on shared examples/helpers |
0 commit comments