@skyramp/mcp/build/prompts/code-reuse.js

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

import { generateSkyrampHeader, SKYRAMP_UTILS_HEADER } from "../utils/utils.js";
const LANGUAGE_MAP = {
    python: {
        extension: "py",
        fileName: "SkyrampUtils.py",
    },
    java: {
        extension: "java",
        fileName: "SkyrampUtils.java",
    },
    javascript: {
        extension: "js",
        fileName: "skyrampUtils.js",
    },
    typescript: {
        extension: "ts",
        fileName: "skyrampUtils.ts",
    },
};
export function getCodeReusePrompt(testFile, language) {
    const ext = LANGUAGE_MAP[language].extension || "py";
    const fileName = LANGUAGE_MAP[language].fileName || "SkyrampUtils.py";
    return `# CODE REUSE - 6 CLEAR STEPS 
**CRITICAL WARNING: VIOLATION OF THESE RULES WILL RESULT IN ERROR**

## DEFINITIONS (READ FIRST):
**What is a "Helper Function"?**
- A helper function is a STANDALONE, DISTINCT function that is ALREADY DEFINED in the code
- It has a clear function signature (e.g., \`async function createProduct(page, data) { ... }\`)
- It is NOT just repetitive inline test code or patterns
- Example of helper function: \`async function loginUser(page, email, password) { ... }\`
- Example of NOT a helper function: Repetitive \`await page.click()\` statements scattered in test

**What is "Repetitive Code Pattern"?**
- Sequential test steps that look similar but are NOT extracted into standalone functions
- Example: Multiple sequences of \`await page.fill()\`, \`await page.click()\` directly in test body
- These patterns should NOT be extracted during code reuse - that's what modularization is for

** CODE REUSE ≠ REFACTORING**
- Code reuse = Finding EXISTING helper functions and reusing them
- Refactoring = Creating NEW helper functions from patterns (handled by modularization tool)

## STEP 1: READ TEST FILE
Read ${testFile} and look for ALREADY DEFINED helper functions (not just repetitive patterns).

## STEP 2: FIND EXISTING UTILS
Use the Grep tool to search for files containing "${SKYRAMP_UTILS_HEADER}":
- Pattern: "${SKYRAMP_UTILS_HEADER}"
- Type: "${ext}"
- Output mode: "files_with_matches"
**CRITICAL: Only look for util files with header ${SKYRAMP_UTILS_HEADER}** - exclude test files (files with "test", "spec", ".test.", ".spec." in the name).
Read the matching non-test files and check if any helpers can be reused in ${testFile}.

## STEP 3: USE EXISTING HELPERS FROM UTILS SOURCE FILES FOUND IN STEP 2
If helpers exist in util file that can be reused in ${testFile} without modifying them:
- Import them into ${testFile}
- Remove any duplicate code in ${testFile}
- Test that ${testFile} still works without any errors and logical is same as original test file.

## STEP 4: FIND LOCAL HELPERS IN OTHER TEST SOURCE FILES THAT HAS HEADER ${SKYRAMP_UTILS_HEADER} 
Use the Grep tool to search for other test files containing "${SKYRAMP_UTILS_HEADER}":
- Pattern: "${SKYRAMP_UTILS_HEADER}"
- Type: "${ext}"
- Output mode: "files_with_matches"
**CRITICAL: Exclude ${testFile} from the results** - only look at OTHER test files, not the current file.

**STOP HERE IF NO OTHER TEST FILES FOUND**
**IF NO OTHER TEST FILES ARE FOUND, SKIP TO STEP 6 - DO NOT CREATE ANY UTILS FILES.**

If other test files are found, read those files and look for ALREADY DEFINED helper functions with clear function signatures.

**How to identify helper functions in other test files:**
 HELPER FUNCTION (move to utils):
   - Has function signature: \`async function doSomething(params) { ... }\`
   - Can be called multiple times with different parameters
   - Example: \`async function fillProductForm(page, product) { ... }\`

NOT A HELPER FUNCTION (do not extract):
   - Just repetitive inline test code in test body
   - No function definition/signature
   - Example: Multiple \`await page.getByTestId("xyz").click()\` directly in test

**IF OTHER TEST FILES ONLY CONTAIN REPETITIVE PATTERNS (NO ACTUAL HELPER FUNCTIONS), SKIP TO STEP 6**
**IF OTHER TEST FILES ARE ESSENTIALLY IDENTICAL TO CURRENT FILE, SKIP TO STEP 6**

## STEP 5: IF LOCAL HELPERS ARE FOUND IN STEP 4 THAT CAN BE REUSED in ${testFile}, MOVE THOSE LOCAL HELPERS TO UTILS SOURCE FILES AND USE THEM

**ONLY PROCEED WITH STEP 5 IF ALL CONDITIONS ARE MET:**
- You found OTHER test files in STEP 4 (not just ${testFile})
- Those test files contain ACTUAL HELPER FUNCTIONS with function signatures (not just repetitive patterns)
- The helper functions are ALREADY IMPLEMENTED and working in those OTHER test files
- The helper functions are DIFFERENT from the current file (not just identical patterns)

**IF ANY CONDITION IS NOT MET, SKIP TO STEP 6 - DO NOT CREATE ANY UTILS FILES.**

**Examples of when to SKIP STEP 5:**
- Other test files have identical repetitive code but no helper functions
- Other test files are generated from same template and look identical
- You see patterns but no actual function definitions
- You would need to CREATE new functions to extract the patterns

**CRITICAL:** For helpers found in STEP 4:
1. **CREATE** \`${fileName}\` file if it doesn't exist with the following header:
   \`\`\`${ext}
   ${generateSkyrampHeader(language)}
   \`\`\`
**CRITICAL: IF \`${fileName}\` is already big, create a new file with a different name and add the header to the new file.**
2. **COPY** those local helper functions from original test source files to \`${fileName}\` without modifying them
3. **DELETE** those local helper functions from test source files (REMOVE THEM COMPLETELY) WITHOUT ANY OTHER CHANGES.
4. **IMPORT** those local helper functions from \`${fileName}\` back into test source files WITHOUT MAKING ANY OTHER CHANGE.
5. **IMPORT** those local helper functions from \`${fileName}\` into ${testFile}
6. **REPLACE** duplicate code in ${testFile} with calls to imported helper functions WITHOUT MAKING ANY OTHER CHANGE.

**CRITICAL: DO NOT CREATE UNNECESSARY HELPER FUNCTIONS** 
**DO NOT CREATE HELPERS BASED ON PATTERNS IN THE CURRENT FILE** 

## STEP 6: VERIFY AND VALIDATE
1. **BEFORE** making any changes, read the original test file and identify ALL helper functions
2. **AFTER** copying helpers to utils, read the original file again to confirm helpers are GONE
3. **VERIFY** that helper functions are NO LONGER in original test files
4. **VERIFY** that the original test files only have import statements and no duplicate code
5. **VERIFY** that both original and new test files import from utils and use the helper functions
6. **VERIFY** that no unnecessary helper functions were created (functions that duplicate existing functionality)
7. **VERIFY** that all helper functions in utils are actually imported and used in the test files
8. **REMOVE** any helper functions that are not being used after refactoring
9. **NEVER** refactor, reorganize, or restructure existing source test files beyond moving helpers
10. **RUN TESTS** to ensure functionality is preserved after refactoring

**FINAL REMINDER: DO NOT CREATE HELPER FUNCTIONS FROM SCRATCH** 
**ONLY MOVE EXISTING HELPERS FROM OTHER TEST FILES** 

**IMPORTANT NOTES:**
- The process is designed to REUSE existing helper functions, not create new ones
- If no existing helpers are found, the test file should remain unchanged
- Code reuse is about moving existing, working helper functions between files
- Never create helper functions based on patterns you see in the current test file
- Helper functions must have explicit function signatures/definitions
- Repetitive inline test code is NOT a helper function

**DECISION TREE:**
1. Found existing utils file with helpers? → Import and use them (Step 3)
2. Found other test files with ACTUAL helper functions? → Move to utils (Step 5)
3. Found other test files with only repetitive patterns? → SKIP to Step 6, NO utils file
4. Found no other test files? → SKIP to Step 6, NO utils file
5. Other test files identical to current? → SKIP to Step 6, NO utils file

**MANDATORY**: After code reuse is complete, proceed to modularization by calling skyramp_modularization tool ONLY for UI, E2E, INTEGRATION or LOAD test types generated from traces.

SUMMARIZE THE CODE REUSE PROCESS AND THE RESULTS.
`;
}