|
| 1 | +# Test Generator Template |
| 2 | + |
| 3 | +This is a **generic, customizable template** for creating test generation workflows. It's designed to be adapted for different projects, testing frameworks, and workflows. |
| 4 | + |
| 5 | +## Why Use This Template? |
| 6 | + |
| 7 | +The pre-configured `/generate-tests` command is optimized for MicroShift/OpenShift projects with specific assumptions about: |
| 8 | +- Jira OCPSTRAT tickets |
| 9 | +- Robot Framework test structure |
| 10 | +- MicroShift repository layout |
| 11 | +- Red Hat workflow conventions |
| 12 | + |
| 13 | +**This template allows you to:** |
| 14 | +- Adapt the workflow for your specific project |
| 15 | +- Use different testing frameworks (Pytest, Jest, Ginkgo, etc.) |
| 16 | +- Customize for different issue trackers (GitHub, Jira, Linear, etc.) |
| 17 | +- Work with Claude Code, Cursor, or any AI assistant |
| 18 | +- Match your team's conventions and preferences |
| 19 | + |
| 20 | +## How to Use This Template |
| 21 | + |
| 22 | +### Option 1: Direct Prompting (Recommended for Cursor users) |
| 23 | +1. **Copy the relevant sections** from this template |
| 24 | +2. **Customize them** for your project |
| 25 | +3. **Paste into your AI assistant** as context with your request |
| 26 | + |
| 27 | +**Example**: |
| 28 | +``` |
| 29 | +I want to generate tests for my project. Here's my setup: |
| 30 | +- Project: MyAPI |
| 31 | +- Issue tracker: GitHub Issues (https://github.com/myorg/myapi/issues/) |
| 32 | +- Test framework: Pytest |
| 33 | +- Directory structure: tests/unit/, tests/integration/ |
| 34 | +
|
| 35 | +[paste customized template sections] |
| 36 | +
|
| 37 | +Please generate tests for issue #123 |
| 38 | +``` |
| 39 | + |
| 40 | +### Option 2: Create a Custom Slash Command (For Claude Code) |
| 41 | +1. **Copy this file** to create your own command (e.g., `.claude/commands/my-generate-tests.md`) |
| 42 | +2. **Customize the sections** below to match your project |
| 43 | +3. **Use the command**: `/my-generate-tests TICKET-ID` |
| 44 | + |
| 45 | +### Option 3: Use as Reference |
| 46 | +Simply reference sections of this template when asking your AI assistant to generate tests, adapting on the fly. |
| 47 | + |
| 48 | +--- |
| 49 | + |
| 50 | +## Template Sections to Customize |
| 51 | + |
| 52 | +### 🎯 Project Context (CUSTOMIZE THIS) |
| 53 | +``` |
| 54 | +Replace with your project details: |
| 55 | +- Project name: [MicroShift/OpenShift/Your Project] |
| 56 | +- Issue tracker: [Jira/GitHub Issues/Linear/etc.] |
| 57 | +- Repository structure: [mono-repo/multi-repo] |
| 58 | +- Test framework: [Robot Framework/Pytest/Jest/etc.] |
| 59 | +``` |
| 60 | + |
| 61 | +### 📋 Ticket Analysis (CUSTOMIZE THIS) |
| 62 | +``` |
| 63 | +Define your ticket workflow: |
| 64 | +- Ticket URL pattern: https://issues.redhat.com/browse/$1 |
| 65 | +- Required ticket fields: [Description, Acceptance Criteria, etc.] |
| 66 | +- Linked tickets to check: [Implementation tickets, dependent tickets] |
| 67 | +- Where to find PR links: [Ticket fields, comments, linked items] |
| 68 | +``` |
| 69 | + |
| 70 | +### 🔍 Test Coverage Analysis (CUSTOMIZE THIS) |
| 71 | +``` |
| 72 | +Define what to analyze: |
| 73 | +- Test file patterns: *.robot, *_test.py, *.spec.js |
| 74 | +- Test directories: test/, tests/, __tests__/ |
| 75 | +- Coverage sources: [PRs, existing test suites, test plans] |
| 76 | +- What constitutes "covered": [Unit tests, integration tests, etc.] |
| 77 | +``` |
| 78 | + |
| 79 | +### ✍️ Test Case Generation (CUSTOMIZE THIS) |
| 80 | +``` |
| 81 | +Define your test case format: |
| 82 | +- Test case document format: [Markdown, Confluence, etc.] |
| 83 | +- Number of test cases: [Top 10, All scenarios, etc.] |
| 84 | +- Test case fields: |
| 85 | + * Test ID format: USHIFT-XXX-TC-YYY |
| 86 | + * Priority levels: Critical/High/Medium/Low |
| 87 | + * Required sections: Description, Steps, Expected Results, etc. |
| 88 | +- Output location: [Current directory, specific folder, etc.] |
| 89 | +``` |
| 90 | + |
| 91 | +### 🧪 Test Categories to Cover (CUSTOMIZE THIS) |
| 92 | +``` |
| 93 | +Define categories relevant to YOUR project: |
| 94 | +1. Core Functionality |
| 95 | +2. Configuration Edge Cases |
| 96 | +3. Dynamic Behavior |
| 97 | +4. Integration Points |
| 98 | +5. Multi-tenant/Namespace |
| 99 | +6. Error Handling |
| 100 | +7. Upgrade/Compatibility |
| 101 | +8. Performance |
| 102 | +9. Security |
| 103 | +10. Real Customer Scenarios |
| 104 | +
|
| 105 | +Add/remove categories as needed for your domain. |
| 106 | +``` |
| 107 | + |
| 108 | +### 🤖 Test Implementation (CUSTOMIZE THIS) |
| 109 | +``` |
| 110 | +Define your test structure: |
| 111 | +- Test framework: Robot Framework / Pytest / Jest / etc. |
| 112 | +- File naming convention: kebab-case / snake_case / PascalCase |
| 113 | +- Directory structure: test/suites/<category>/ or tests/unit/ |
| 114 | +- Reusable components location: resources/, utils/, fixtures/ |
| 115 | +- Setup/Teardown patterns: Your project's patterns |
| 116 | +``` |
| 117 | + |
| 118 | +### 📁 File Organization (CUSTOMIZE THIS) |
| 119 | +``` |
| 120 | +Map feature types to test directories: |
| 121 | +- Network features → test/suites/network/ |
| 122 | +- Storage features → test/suites/storage/ |
| 123 | +- API features → test/api/ |
| 124 | +- UI features → test/e2e/ |
| 125 | +
|
| 126 | +Customize based on YOUR project structure. |
| 127 | +``` |
| 128 | + |
| 129 | +### 🔧 Keyword/Helper Reuse (CUSTOMIZE THIS - Robot Framework specific) |
| 130 | +``` |
| 131 | +If using Robot Framework, define: |
| 132 | +- Common keyword locations: test/extended/util/*.robot |
| 133 | +- Resource file patterns: resources/**/*.robot |
| 134 | +- Naming conventions: Action_Object pattern |
| 135 | +- When to create new vs. reuse: Your team's guidelines |
| 136 | +``` |
| 137 | + |
| 138 | +### 🌿 Git Workflow (CUSTOMIZE THIS) |
| 139 | +``` |
| 140 | +Define your branching strategy: |
| 141 | +- Branch naming: test-OCPSTRAT-XXXX-$(date +%Y%m%d) or feature/tests-XXX |
| 142 | +- Base branch: main / master / develop |
| 143 | +- Commit message format: Your team's convention |
| 144 | +- Auto-commit: Yes/No (get confirmation first) |
| 145 | +- Repository location: Ask user / fixed path / auto-detect |
| 146 | +``` |
| 147 | + |
| 148 | +### 📊 Output Format (CUSTOMIZE THIS) |
| 149 | +``` |
| 150 | +Define what the final output should include: |
| 151 | +- Test case document: Format and location |
| 152 | +- Test implementation files: Locations and count |
| 153 | +- Coverage report: What was tested vs. what's missing |
| 154 | +- Summary report: Tickets analyzed, PRs reviewed, etc. |
| 155 | +- Next steps: Instructions for running tests, creating PR, etc. |
| 156 | +``` |
| 157 | + |
| 158 | +--- |
| 159 | + |
| 160 | +## Example Customized Prompt |
| 161 | + |
| 162 | +Here's an example of how to customize this template for a different project: |
| 163 | + |
| 164 | +### Example: Python/Pytest Project |
| 165 | + |
| 166 | +```markdown |
| 167 | +# Pytest Test Generator for MyAPI Project |
| 168 | + |
| 169 | +Generate comprehensive Pytest coverage for MyAPI features based on GitHub Issues. |
| 170 | + |
| 171 | +## Workflow: |
| 172 | + |
| 173 | +### Step 1: Analyze GitHub Issue |
| 174 | +- Fetch issue from: https://github.com/myorg/myapi/issues/$1 |
| 175 | +- Extract feature description and acceptance criteria |
| 176 | +- Find linked PRs in issue body and comments |
| 177 | + |
| 178 | +### Step 2: Analyze Existing Tests |
| 179 | +- Check for test files: tests/**/*_test.py |
| 180 | +- Look for pytest fixtures in: tests/conftest.py |
| 181 | +- Identify what's already covered |
| 182 | + |
| 183 | +### Step 3: Generate Test Cases |
| 184 | +- Create markdown document: test_cases_issue_$1.md |
| 185 | +- Generate 5-7 critical test scenarios |
| 186 | +- Format: Given/When/Then style |
| 187 | +- Include: unit tests, integration tests, edge cases |
| 188 | + |
| 189 | +### Step 4: Implement Pytest Tests |
| 190 | +- Create test file: tests/unit/test_<feature>.py |
| 191 | +- Reuse fixtures from conftest.py |
| 192 | +- Follow pytest best practices |
| 193 | +- Use parametrize for multiple scenarios |
| 194 | + |
| 195 | +### Step 5: Update conftest.py if needed |
| 196 | +- Add new fixtures only if truly reusable |
| 197 | +- Document fixture purpose and scope |
| 198 | + |
| 199 | +### Step 6: Create PR (optional) |
| 200 | +- Branch: feature/tests-issue-$1 |
| 201 | +- Run: pytest tests/ to verify |
| 202 | +- Provide summary of coverage added |
| 203 | +``` |
| 204 | + |
| 205 | +--- |
| 206 | + |
| 207 | +## Instructions for AI Assistants |
| 208 | + |
| 209 | +When a user provides this template: |
| 210 | + |
| 211 | +1. **Ask clarifying questions** about sections marked "CUSTOMIZE THIS" |
| 212 | +2. **Don't assume** - let the user specify their preferences |
| 213 | +3. **Adapt the workflow** to the user's specific tools and conventions |
| 214 | +4. **Confirm before creating files/branches** - respect the user's workflow |
| 215 | +5. **Be flexible** - this is a starting point, not a rigid spec |
| 216 | + |
| 217 | +--- |
| 218 | + |
| 219 | +## Tips for Customization |
| 220 | + |
| 221 | +### For Different Testing Frameworks |
| 222 | +- **Pytest**: Focus on fixtures, parametrize, conftest.py |
| 223 | +- **Jest**: Focus on mocks, setup/teardown, snapshot testing |
| 224 | +- **Robot Framework**: Focus on keywords, resources, libraries |
| 225 | +- **Selenium**: Focus on page objects, waits, selectors |
| 226 | +- **Postman/REST**: Focus on request builders, assertions, environments |
| 227 | + |
| 228 | +### For Different Issue Trackers |
| 229 | +- **GitHub Issues**: Use GitHub API or web scraping |
| 230 | +- **Jira**: Adjust ticket URL pattern, field names |
| 231 | +- **Linear**: Different API structure |
| 232 | +- **Azure DevObs**: Work items structure |
| 233 | + |
| 234 | +### For Different Project Types |
| 235 | +- **Microservices**: Multi-repo coordination, API contracts |
| 236 | +- **Frontend**: Component testing, accessibility, visual regression |
| 237 | +- **CLI Tools**: Command execution, output validation, error handling |
| 238 | +- **Libraries**: API testing, documentation examples, edge cases |
| 239 | + |
| 240 | +--- |
| 241 | + |
| 242 | +## License |
| 243 | + |
| 244 | +This template is provided as-is for customization. Adapt freely to your needs. |
0 commit comments