@skyramp/mcp 0.0.22 → 0.0.23
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -12,7 +12,6 @@ Only if NO existing function can be reused:
|
|
|
12
12
|
3. KEEP CHANGES TO A MINIMUM. DO NOT MODIFY THE FUNCTIONALITY OF THE TESTS. ONLY MODULARIZE THE CODE.
|
|
13
13
|
4. Parameterize the test function(s) with meaningful parameters to make it more flexible. Preserve the original order of code lines within each function.
|
|
14
14
|
5. Only extract reusable logical sections into helper functions. Use inline parameter types instead of creating interfaces or type definitions.
|
|
15
|
-
6. **If extracting UI operations, ensure each helper function is self-contained** and leaves the UI in a clean state for the next operation WITHOUT UPDATING THE LOGIC OF THE TESTS.
|
|
16
15
|
|
|
17
16
|
**CRITICAL CONSTRAINTS:**
|
|
18
17
|
- NO interfaces, classes, types, or data structures
|
|
@@ -38,3 +37,133 @@ export function getFixErrorsPrompt() {
|
|
|
38
37
|
**UI KEY: Helper functions that perform UI operations must be self-contained and not leave modals/dialogs open.**
|
|
39
38
|
`;
|
|
40
39
|
}
|
|
40
|
+
export function getModularizationPromptForUI(filePath, language) {
|
|
41
|
+
return `
|
|
42
|
+
**CRITICAL: Refactor code with modularization principles. Respond with complete, modularized code only WITHOUT ERRORS AND WRITTEN BACK TO THE FILE ${filePath}**
|
|
43
|
+
|
|
44
|
+
**CRITICAL: DO NOT CHANGE THE FUNCTIONALITY OF THE TESTS. ONLY MODULARIZE THE CODE.**
|
|
45
|
+
|
|
46
|
+
**ABSOLUTELY FORBIDDEN: DO NOT CREATE ANY INTERFACES, CLASSES, TYPES, OR NEW DATA STRUCTURES. USE INLINE TYPES ONLY.**
|
|
47
|
+
|
|
48
|
+
**COMMON UI TEST FAILURE: Many UI tests fail after modularization because navigation steps between similar operations are incorrectly moved into helper functions. This breaks the test flow and causes timeouts.**
|
|
49
|
+
|
|
50
|
+
**COMMON CALCULATION FAILURE: UI tests fail when complex logic patterns (loops, conditionals, array handling) are incorrectly generalized in helper functions, causing wrong quantities, prices, or missing operations.**
|
|
51
|
+
|
|
52
|
+
**MANDATORY ANALYSIS BEFORE MODULARIZATION:**
|
|
53
|
+
Before creating any helper functions, identify ALL critical patterns in the original test:
|
|
54
|
+
- Look for patterns like: page.getByTestId("navbar-*").click()
|
|
55
|
+
- Look for patterns like: page.goto()
|
|
56
|
+
- Look for patterns like: page.goBack()
|
|
57
|
+
- Look for complex loops with conditionals or null handling
|
|
58
|
+
- Look for unique sequences that differ between similar operations
|
|
59
|
+
- These MUST remain in the main test function in their EXACT original positions and logic
|
|
60
|
+
|
|
61
|
+
**CRITICAL RULE: If the original test performs operations in a specific sequence with unique logic for each step, DO NOT generalize this into a loop or helper function. Keep the exact original sequence.**
|
|
62
|
+
|
|
63
|
+
STEPS:
|
|
64
|
+
1. **PRESERVE EXACT UI SEQUENCE**: For UI TESTS, maintain the EXACT sequence of UI interactions. Do NOT extract steps that break the natural flow.
|
|
65
|
+
2. **CAREFUL EXTRACTION**: Only extract helper functions for COMPLETE, REPEATABLE workflows that do NOT include navigation between different pages/sections and do NOT contain complex conditional logic.
|
|
66
|
+
3. **PRESERVE UNIQUE STEPS**: If a workflow has unique steps (like clicking specific labels), DO NOT extract it into a generic helper function.
|
|
67
|
+
4. **PRESERVE COMPLEX LOGIC**: If the original test has loops, conditionals, or array processing with unique patterns, DO NOT generalize these - keep them exactly as written.
|
|
68
|
+
5. **RESPONSE PROMISES**: Maintain the exact timing of response promise creation and awaiting. Do not move these into helper functions unless the entire request-response cycle is contained.
|
|
69
|
+
6. **PARAMETERIZATION**: When creating helper functions, ensure ALL required parameters (page, data objects, response promises) are passed correctly.
|
|
70
|
+
7. **VALIDATION**: Each extracted function must work independently without relying on external scope variables.
|
|
71
|
+
8. **PRESERVE ORIGINAL FLOW**: If the original code has different patterns for similar operations (like product creation), preserve those differences - they exist for a reason.
|
|
72
|
+
9. **NAVIGATION PRESERVATION**: CRITICAL - If the original test has navigation steps between similar operations (like clicking "navbar-products" between product creations), these MUST be preserved in the main test flow, NOT moved into helper functions.
|
|
73
|
+
|
|
74
|
+
**WHAT SHOULD BE EXTRACTED (SAFE TO EXTRACT):**
|
|
75
|
+
- Simple form filling sequences within a single page/modal
|
|
76
|
+
- Basic button clicking sequences within a single workflow
|
|
77
|
+
- Simple data entry that doesn't change page state
|
|
78
|
+
- Basic assertions and validations within the same page context
|
|
79
|
+
|
|
80
|
+
**WHAT SHOULD NEVER BE EXTRACTED (KEEP IN MAIN TEST):**
|
|
81
|
+
- Navigation between pages (navbar clicks, page.goto)
|
|
82
|
+
- Steps that change the overall page context
|
|
83
|
+
- Sequences that span multiple pages or sections
|
|
84
|
+
- Any step that affects where the user is in the application
|
|
85
|
+
- Complex loops with conditionals or special handling
|
|
86
|
+
- Operations with unique patterns that differ between similar workflows
|
|
87
|
+
- Array processing with null handling or special indexing
|
|
88
|
+
|
|
89
|
+
**CRITICAL CONSTRAINTS:**
|
|
90
|
+
- NO interfaces, classes, types, or data structures
|
|
91
|
+
- NO changes to the core UI interaction sequence
|
|
92
|
+
- NO extraction of partial workflows that depend on external state
|
|
93
|
+
- NO generalization of complex logic patterns into loops or helper functions
|
|
94
|
+
- ONLY extract COMPLETE, self-contained operations that occur within the same page context
|
|
95
|
+
- PRESERVE original functionality exactly
|
|
96
|
+
- DO NOT extract steps that have unique UI interactions
|
|
97
|
+
- DO NOT move navigation steps (like navbar clicks) into helper functions - keep them in the main test flow
|
|
98
|
+
- PRESERVE all navigation between similar operations exactly as in the original test
|
|
99
|
+
- NAVIGATION STEPS MUST REMAIN IN THE MAIN TEST FUNCTION TO MAINTAIN PROPER PAGE STATE
|
|
100
|
+
- COMPLEX LOGIC PATTERNS MUST REMAIN IN THE MAIN TEST FUNCTION TO MAINTAIN EXACT BEHAVIOR
|
|
101
|
+
|
|
102
|
+
**BEFORE SUBMITTING: Double-check that every navigation step and complex operation from the original test appears in the same position with the same logic in the main test function.**
|
|
103
|
+
|
|
104
|
+
**CRITICAL: If you skip any step, the modularization is incomplete. You MUST complete all steps before proceeding.FIX ERRORS IN MODULARIZED CODE USING skyramp_fix_errors TOOL**
|
|
105
|
+
`;
|
|
106
|
+
}
|
|
107
|
+
export function getFixErrorsPromptForUI() {
|
|
108
|
+
return `
|
|
109
|
+
**Fix errors in refactored code.**
|
|
110
|
+
|
|
111
|
+
**COMMON UI TEST TIMEOUT ERROR: Test timeouts often occur when navigation steps are incorrectly moved into helper functions, causing the page to be in the wrong state when trying to interact with elements.**
|
|
112
|
+
|
|
113
|
+
**COMMON UI TEST CALCULATION ERROR: Order totals, quantities, or other calculated values may be incorrect if the original test's unique logic was incorrectly generalized in helper functions.**
|
|
114
|
+
|
|
115
|
+
**IMMEDIATE TIMEOUT DEBUGGING STEPS:**
|
|
116
|
+
1. Compare the original test and modularized test side by side
|
|
117
|
+
2. Identify every navigation step in the original (navbar clicks, page.goto, etc.)
|
|
118
|
+
3. Verify each navigation step appears in the EXACT same position in the main test function
|
|
119
|
+
4. If any navigation step was moved into a helper function, move it back to the main test
|
|
120
|
+
|
|
121
|
+
**IMMEDIATE CALCULATION ERROR DEBUGGING STEPS:**
|
|
122
|
+
1. Compare the exact sequence of operations in the original vs modularized test
|
|
123
|
+
2. Check if helper functions are skipping steps that the original test performed
|
|
124
|
+
3. Verify that loops and conditional logic in helper functions match the original exactly
|
|
125
|
+
4. Look for cases where null/empty values in data arrays are handled differently
|
|
126
|
+
|
|
127
|
+
**DETAILED FIX STEPS:**
|
|
128
|
+
1. **UI Sequence Validation**: Verify that the exact UI interaction sequence from the original test is preserved. Check for missing clicks, form openings, or navigation steps.
|
|
129
|
+
2. **Navigation Step Preservation**: CRITICAL - Ensure all navigation steps between similar operations (like "navbar-products" clicks between product creations) are preserved in the main test flow, not moved into helper functions.
|
|
130
|
+
3. **Page State Debugging**: If test is timing out on element interactions, check if the page is in the expected state. Often this means navigation steps were incorrectly extracted.
|
|
131
|
+
4. **Logic Preservation**: If test has incorrect calculations or missing operations, check if helper functions are generalizing logic that should remain unique to each operation.
|
|
132
|
+
5. **Parameter Passing**: Identify functions using variables from outside scope (like 'page' object, response promises, test data). Pass these as parameters.
|
|
133
|
+
6. **Response Promise Timing**: Ensure response promises are created and awaited at the exact same points as the original test.
|
|
134
|
+
7. **Unique Workflow Preservation**: If the original test has unique steps for similar operations, ensure these are preserved and not generalized incorrectly.
|
|
135
|
+
8. **Complete Workflow Validation**: Ensure that extracted helper functions contain COMPLETE workflows, not partial steps that depend on external state.
|
|
136
|
+
9. **Page State Management**: Verify that helper functions don't assume specific page states - the main test should handle navigation between different pages/states.
|
|
137
|
+
10. **Validate Correctness**: Ensure code is free of reference errors, undefined variables, runtime issues.
|
|
138
|
+
11. **Import Paths**: Ensure import paths are correct and there are no circular imports.
|
|
139
|
+
|
|
140
|
+
**TIMEOUT DEBUGGING CHECKLIST:**
|
|
141
|
+
- Are all navigation steps (navbar clicks, page.goto) in the main test function?
|
|
142
|
+
- Do helper functions only contain self-contained operations without navigation?
|
|
143
|
+
- Is the page in the expected state before each helper function call?
|
|
144
|
+
- Are there any missing navigation steps between operations?
|
|
145
|
+
- Compare line-by-line: does the main test flow match the original test flow exactly?
|
|
146
|
+
|
|
147
|
+
**CALCULATION ERROR DEBUGGING CHECKLIST:**
|
|
148
|
+
- Are all operations from the original test being performed in the modularized version?
|
|
149
|
+
- Do helper functions handle null/empty values the same way as the original?
|
|
150
|
+
- Are loops and conditionals in helper functions exact matches to the original logic?
|
|
151
|
+
- Are quantities, prices, and other data values being processed identically?
|
|
152
|
+
|
|
153
|
+
**SPECIFIC FIX FOR COMMON ERROR:**
|
|
154
|
+
If you see timeout on "Add Product" button after product creation:
|
|
155
|
+
- Check if navbar-products click was moved into a helper function
|
|
156
|
+
- Move it back to the main test function between product creation calls
|
|
157
|
+
- The page must navigate back to products listing before trying to add another product
|
|
158
|
+
|
|
159
|
+
If you see incorrect order totals or missing items:
|
|
160
|
+
- Check if the original test has unique patterns for adding items that were incorrectly generalized
|
|
161
|
+
- Verify that all items from the original test are being added in the modularized version
|
|
162
|
+
- Look for cases where null values or special array handling was changed
|
|
163
|
+
|
|
164
|
+
**KEY: Every UI interaction from the original test must be present in the modularized version.**
|
|
165
|
+
**CRITICAL: Helper functions should only contain COMPLETE, self-contained workflows.**
|
|
166
|
+
**NAVIGATION KEY: Navigation steps between operations must remain in the main test flow to maintain proper page state.**
|
|
167
|
+
**CALCULATION KEY: Unique logic patterns should not be generalized if they produce different results.**
|
|
168
|
+
`;
|
|
169
|
+
}
|
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
import { getModularizationPrompt } from "../prompts/modularization-prompts.js";
|
|
1
|
+
import { getModularizationPrompt, getModularizationPromptForUI, } from "../prompts/modularization-prompts.js";
|
|
2
2
|
export class ModularizationService {
|
|
3
3
|
constructor() { }
|
|
4
4
|
async processModularizationRequest(params) {
|
|
@@ -6,7 +6,9 @@ export class ModularizationService {
|
|
|
6
6
|
content: [
|
|
7
7
|
{
|
|
8
8
|
type: "text",
|
|
9
|
-
text: `${
|
|
9
|
+
text: `${params.testType === "ui"
|
|
10
|
+
? getModularizationPromptForUI(params.testFile, params.language)
|
|
11
|
+
: getModularizationPrompt(params.testFile, params.language)}`,
|
|
10
12
|
},
|
|
11
13
|
],
|
|
12
14
|
};
|
|
@@ -31,7 +31,7 @@ export class TestGenerationService {
|
|
|
31
31
|
const shouldModularize = testType === "ui" || testType === "e2e" || testType === "integration";
|
|
32
32
|
const languageSteps = getLanguageSteps({
|
|
33
33
|
language: params.language || "",
|
|
34
|
-
testType:
|
|
34
|
+
testType: testType,
|
|
35
35
|
framework: params.framework,
|
|
36
36
|
});
|
|
37
37
|
return {
|
|
@@ -2,13 +2,16 @@ import { z } from "zod";
|
|
|
2
2
|
import { ModularizationService, } from "../services/ModularizationService.js";
|
|
3
3
|
import { logger } from "../utils/logger.js";
|
|
4
4
|
const modularizationSchema = {
|
|
5
|
-
prompt: z
|
|
6
|
-
.string()
|
|
7
|
-
.describe("The prompt or code content to process with modularization principles applied"),
|
|
8
5
|
testFile: z
|
|
9
6
|
.string()
|
|
10
7
|
.describe("The test file to process with modularization principles applied"),
|
|
11
8
|
language: z.string().describe("The programming language of the test file"),
|
|
9
|
+
testType: z
|
|
10
|
+
.string()
|
|
11
|
+
.describe("The type of test (ui, e2e, integration, api, etc.)"),
|
|
12
|
+
prompt: z
|
|
13
|
+
.string()
|
|
14
|
+
.describe("The prompt or code content to process with modularization principles applied"),
|
|
12
15
|
};
|
|
13
16
|
export function registerModularizationTool(server) {
|
|
14
17
|
server.registerTool("skyramp_modularization", {
|
|
@@ -28,6 +31,7 @@ export function registerModularizationTool(server) {
|
|
|
28
31
|
testFile: params.testFile,
|
|
29
32
|
language: params.language,
|
|
30
33
|
prompt: params.prompt,
|
|
34
|
+
testType: params.testType,
|
|
31
35
|
});
|
|
32
36
|
const service = new ModularizationService();
|
|
33
37
|
return await service.processModularizationRequest(params);
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@skyramp/mcp",
|
|
3
|
-
"version": "0.0.
|
|
3
|
+
"version": "0.0.23",
|
|
4
4
|
"main": "build/index.js",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"bin": {
|
|
@@ -42,7 +42,7 @@
|
|
|
42
42
|
},
|
|
43
43
|
"dependencies": {
|
|
44
44
|
"@modelcontextprotocol/sdk": "^1.11.4",
|
|
45
|
-
"@skyramp/skyramp": "^1.2.
|
|
45
|
+
"@skyramp/skyramp": "^1.2.17",
|
|
46
46
|
"dockerode": "^4.0.6",
|
|
47
47
|
"zod": "^3.25.3"
|
|
48
48
|
},
|