@skyramp/mcp/build/prompts/modularization/ui-test-modularization.js

Skyramp MCP (Model Context Protocol) Server - AI-powered test generation and execution

export function getModularizationPrompt(filePath) {
    return `# UI TEST MODULARIZATION - IMPROVE READABILITY AND REDUCE DUPLICATION

**CRITICAL: Use the 'write' tool to save the modularized code to: ${filePath}**
**DO NOT use search_replace - use the 'write' tool to overwrite the entire file with the modularized version**

**ABSOLUTELY FORBIDDEN:**
- DO NOT CREATE INTERFACES, CLASSES, TYPES, NEW FILES, OR NEW DATA STRUCTURES
- DO NOT CHANGE TEST LOGIC, DATA VALUES, CALCULATIONS, OR ASSERTIONS
- DO NOT CREATE/UPDATE  DEPENDENCY FILES package.json, requirements.txt, pom.xml, build.gradle file

## STEP 1: READ THE ORIGINAL TEST
Read ${filePath} completely and identify:
- All test data values (names, prices, quantities, totals)
- All test data including calculations and expected results 
- The exact test flow
- **Check if code is already modularized** (e.g., \`breakpoint_section_0\`, \`breakpoint_section_1\` functions)

## STEP 2: HANDLE PRE-MODULARIZED CODE

**IF CODE IS ALREADY MODULARIZED** (has functions like \`breakpoint_section_0\`, \`breakpoint_section_1\`):
1. **RENAME** functions with meaningful names that describe what they do
   - BAD: \`breakpoint_section_0\`, \`breakpoint_section_1\`
   - GOOD: \`createProduct\`, \`editProductPrice\`, \`createOrder\`
2. **PARAMETERIZE** hardcoded values in these functions
3. **DO NOT** change the function logic or structure
4. **DO NOT** create new functions - work with existing ones
5. **SKIP to STEP 5** for verification

**IF CODE IS NOT MODULARIZED**, proceed to STEP 3.

## STEP 3: IDENTIFY EXTRACTION OPPORTUNITIES

Extract code in TWO scenarios:

**A) REPETITIVE CODE** - Code that repeats 2+ times with IDENTICAL structure but different data
- Extract EACH occurrence as a separate helper call
- Don't try to "unify" variations with conditional logic

**B) LOGICAL SECTIONS** - Self-contained operations (5+ lines) that improve readability
- Examples: "create product", "fill form", "verify result"
- Must be cohesive - related operations that achieve one goal

**Don't extract:**
- Code less than 5 lines (unless highly repetitive)
- Navigation sequences (\`navbar-\` clicks, \`page.goto\`)

## STEP 3: EXTRACT INTO HELPERS

**GOLDEN RULE: Copy the original code exactly, only add parameters for values that differ**

**CRITICAL - AVOID BUGS:**
- Copy the code block EXACTLY as-is from the original test
- **NEVER generalize selectors** - Keep selectors exactly as they are in the original code
  - CORRECT: \`await page.getByTestId("product-Product-2-price").toContainText("$444.00")\`
  - WRONG: \`await page.getByTestId("product-\${name}-price").toContainText("$\${price}.00")\`
  - DO NOT refactor hardcoded selectors into dynamic template strings with variables
- **VERIFY ALL field mappings** - EVERY \`.fill()\` must use the correct parameter
  - CORRECT: quantity field → \`.fill(quantity.toString())\`
  - WRONG: quantity field → \`.fill("12")\` then \`.fill(quantity.toString())\` - remove hardcoded "12"!
  - WRONG: name field → \`.fill(description)\` - fields must match their data!
- **Replace ALL hardcoded values with parameters** - No leftover hardcoded fills (selectors are the ONLY exception: selectors must remain exactly as in the original code)
- **NEVER create new conditional logic** (no ternaries, no if/else, no loops to derive parameter values)
- **NEVER add logic that wasn't in the original code**
- Keep ALL existing logic, calculations, and assertions unchanged
- Keep ALL lines in the same order (except: remove fills with wrong/temporary hardcoded values)

**PARAMETERIZATION BEST PRACTICES:**
1. **Use individual parameters, not data objects** - Makes helper usage clearer
   - GOOD: \`createProduct(page, name, price, category)\`
   - BAD: \`createProduct(page, productData)\` - unclear what fields are needed

2. **Avoid nested helpers** - Keep helpers flat and independent
   - GOOD: One helper does the complete operation
   - BAD: Helper calls another helper - adds complexity

3. **No duplicate helpers** - If you have 2+ helpers doing similar things, consolidate them
   - GOOD: One \`createOrder(email, items)\` handles both simple and complex orders
   - BAD: \`createSimpleOrder\` and \`createOrderWithItems\` - consolidate into one
   - Exception: Keep separate if it significantly improves readability

4. **For repetitive code**: Only parameterize values that DIFFER between occurrences

5. **NEVER compute parameters**: Pass literal values directly, don't create logic to derive them

6. **If you need conditionals to choose parameter values, extract each case separately instead**

7. **Loops in helpers**: Generally avoid, but acceptable if:
   - The loop existed in the original code, OR
   - It significantly improves readability without changing test behavior
   - Example: Looping through order items is acceptable if each item is explicitly listed at call site

**NAVIGATION RULE:**
- Keep \`navbar-\` clicks and main \`page.goto\` in the test body
- Exception: Helper can include \`page.goto\` to navigate back after form submissions that redirect

**WRONG - Bad practices:**
\`\`\`typescript
// DON'T DO THIS - Adding conditional logic to handle multiple cases
async function addItem(page, index: number) {
  const name = index === 1 ? "item1" : index === 2 ? "item2" : "item3";
  await page.fill("#name", name);
}

// DON'T DO THIS - Duplicate actions
async function createProduct(page, name) {
  await page.click("#add-button");  // Helper clicks button
  // ... rest of product creation
}
// Then in test:
await page.click("#add-button");  // Test ALSO clicks button - DUPLICATE!
await createProduct(page, "item1");

// DON'T DO THIS - Multiple helpers for same operation
async function createSimpleOrder(...) { }
async function createOrderWithItems(...) { }
// Should be ONE helper: createOrder(page, email, items)
\`\`\`

**RIGHT - Good practices:**
\`\`\`typescript
// CORRECT - Extract with parameter, no new logic
async function addItem(page, name: string) {
  await page.fill("#name", name);  // Replace literal with parameter
}

// CORRECT - Call helper for EACH original occurrence
await addItem(page, "item1");
await addItem(page, "item2");
await addItem(page, "item3");

\`\`\`

## STEP 4: CALL HELPERS WITH EXACT SAME VALUES
Use the EXACT same values from the original test when calling helpers.

## STEP 5: VERIFY - CRITICAL CHECKS

**BUGS TO AVOID:**
- [ ] **NO TYPE ANNOTATIONS FOR \`page\` IN FUNCTION SIGNATURES** - Parameters must be untyped (e.g., \`page\`, not \`page: Page\`)
- [ ] **NO RETURN TYPES** - Do not add \`: Promise<void>\` or any return type annotations
- [ ] **ALL field mappings verified** - EVERY \`.fill()\` uses the correct parameter. Check field gets quantity parameter, NOT hardcoded 
- [ ] **No duplicate helpers** - Consolidate similar helpers (e.g., one createOrder vs createSimpleOrder + createOrderWithItems)
- [ ] **No nested helpers** - Helpers don't call other helpers unnecessarily
- [ ] **Clear parameters** - Individual parameters (name, price) not data objects
- [ ] **No duplicate actions** - Don't click "Add Product" button in test AND in helper - choose one place
- [ ] **No new loops** - Exception: acceptable if it improves readability and items are explicit at call site

**DATA INTEGRITY:**
- [ ] Helpers are exact copies of original + parameters only
- [ ] All data values match the original test exactly
- [ ] All calculations produce identical results
- [ ] Helper calls use the same values as original
- [ ] No navigation code in helpers (except page.goto for state)
- [ ] No duplicate code in main test

**READABILITY:**
- [ ] Helper names clearly describe what they do
- [ ] Test flow is easy to follow
- [ ] Helper signatures are clear (individual params > data objects)

**FINAL CHECK:**
1. Does the modularized test perform the exact same operations?
2. With the exact same data?
3. Expecting the exact same results?
4. Is it MORE readable than the original?

If ANY answer is "no", fix it before submitting.

**When in doubt, don't extract - keep original code unchanged.**`;
}