@autobe/agent 0.9.1 → 0.9.2

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.
Files changed (46) hide show
  1. package/lib/AutoBeAgent.js +5 -1
  2. package/lib/AutoBeAgent.js.map +1 -1
  3. package/lib/constants/AutoBeSystemPromptConstant.d.ts +5 -3
  4. package/lib/constants/AutoBeSystemPromptConstant.js.map +1 -1
  5. package/lib/context/IAutoBeApplicationProps.d.ts +0 -61
  6. package/lib/factory/createAutoBeApplication.js +15 -135
  7. package/lib/factory/createAutoBeApplication.js.map +1 -1
  8. package/lib/index.mjs +247 -248
  9. package/lib/index.mjs.map +1 -1
  10. package/lib/orchestrate/analyze/orchestrateAnalyze.js +4 -30
  11. package/lib/orchestrate/analyze/orchestrateAnalyze.js.map +1 -1
  12. package/lib/orchestrate/interface/orchestrateInterface.js +9 -3
  13. package/lib/orchestrate/interface/orchestrateInterface.js.map +1 -1
  14. package/lib/orchestrate/test/compileTestScenario.js +1 -0
  15. package/lib/orchestrate/test/compileTestScenario.js.map +1 -1
  16. package/lib/orchestrate/test/orchestrateTest.js.map +1 -1
  17. package/lib/orchestrate/test/orchestrateTestCorrect.js +130 -31
  18. package/lib/orchestrate/test/orchestrateTestCorrect.js.map +1 -1
  19. package/lib/orchestrate/test/orchestrateTestScenario.js +98 -83
  20. package/lib/orchestrate/test/orchestrateTestScenario.js.map +1 -1
  21. package/lib/orchestrate/test/orchestrateTestWrite.js +17 -3
  22. package/lib/orchestrate/test/orchestrateTestWrite.js.map +1 -1
  23. package/lib/orchestrate/test/structures/IAutoBeTestScenarioApplication.d.ts +18 -20
  24. package/lib/orchestrate/test/structures/IAutoBeTestScenarioArtifacts.d.ts +2 -0
  25. package/lib/orchestrate/test/transformTestCorrectHistories.d.ts +1 -1
  26. package/lib/orchestrate/test/transformTestCorrectHistories.js +32 -6
  27. package/lib/orchestrate/test/transformTestCorrectHistories.js.map +1 -1
  28. package/lib/orchestrate/test/transformTestWriteHistories.js +13 -1
  29. package/lib/orchestrate/test/transformTestWriteHistories.js.map +1 -1
  30. package/lib/structures/IAutoBeProps.d.ts +12 -1
  31. package/package.json +4 -5
  32. package/src/AutoBeAgent.ts +9 -1
  33. package/src/constants/AutoBeSystemPromptConstant.ts +5 -3
  34. package/src/context/IAutoBeApplicationProps.ts +0 -62
  35. package/src/orchestrate/analyze/orchestrateAnalyze.ts +4 -34
  36. package/src/orchestrate/interface/orchestrateInterface.ts +7 -0
  37. package/src/orchestrate/test/compileTestScenario.ts +1 -0
  38. package/src/orchestrate/test/orchestrateTest.ts +9 -4
  39. package/src/orchestrate/test/orchestrateTestCorrect.ts +197 -36
  40. package/src/orchestrate/test/orchestrateTestScenario.ts +17 -3
  41. package/src/orchestrate/test/orchestrateTestWrite.ts +43 -15
  42. package/src/orchestrate/test/structures/IAutoBeTestScenarioApplication.ts +18 -20
  43. package/src/orchestrate/test/structures/IAutoBeTestScenarioArtifacts.ts +3 -0
  44. package/src/orchestrate/test/transformTestCorrectHistories.ts +33 -5
  45. package/src/orchestrate/test/transformTestWriteHistories.ts +12 -0
  46. package/src/structures/IAutoBeProps.ts +17 -1
@@ -63,7 +63,7 @@ function orchestrateTestScenario(ctx) {
63
63
  const exclude = [];
64
64
  let include = Array.from(operations);
65
65
  do {
66
- const matrix = (0, divideArray_1.divideArray)({ array: include, capacity: 30 });
66
+ const matrix = (0, divideArray_1.divideArray)({ array: include, capacity: 5 });
67
67
  yield Promise.all(matrix.map((_include) => __awaiter(this, void 0, void 0, function* () {
68
68
  exclude.push(...(yield execute(ctx, operations, _include, exclude.map((x) => x.endpoint))));
69
69
  })));
@@ -83,7 +83,7 @@ function orchestrateTestScenario(ctx) {
83
83
  endpoint: pg.endpoint,
84
84
  draft: plan.draft,
85
85
  functionName: plan.functionName,
86
- dependencies: plan.dependsOn,
86
+ dependencies: plan.dependencies,
87
87
  };
88
88
  });
89
89
  }),
@@ -127,23 +127,35 @@ const createHistoryProperties = (operations, include, exclude) => [
127
127
  id: (0, uuid_1.v4)(),
128
128
  created_at: new Date().toISOString(),
129
129
  type: "systemMessage",
130
- text: "You are the AutoAPI Test Scenario Generator.\n\nYour job is to analyze an array of API operation objects and generate realistic, structured test scenario drafts for each operation.\n\n---\n\n## Input Format\n\nYou will receive an array of `Operation` objects structured like this:\n\n```ts\n{\n method: \"post\" | \"get\" | \"put\" | \"patch\" | \"delete\",\n path: \"/path/to/resource\",\n specification: string, // API specification with business logic and constraints\n description: string, // Multi-paragraph description\n summary: string, // One-line summary\n parameters: [...], // List of path/query/body parameters\n requestBody?: {\n typeName: string,\n description: string\n },\n responseBody: {\n typeName: string,\n description: string\n }\n}\n```\n\n---\n\n## Output Format\n\nYour output must be an array of grouped test plans, using the following structure:\n\n```ts\n[\n {\n method: \"post\",\n path: \"/shopping/products\",\n plans: [\n {\n draft: \"Test product creation by submitting two requests with the same product.pid. Confirm that the second request returns a uniqueness constraint error.\",\n dependsOn: [\n {\n method: \"post\",\n path: \"/shopping/categories\",\n purpose: \"Create a category beforehand so the product can reference it.\"\n },\n {\n method: \"get\",\n path: \"/users/me\",\n purpose: \"Verify a valid user session and obtain user context for the test.\"\n }\n ]\n },\n {\n draft: \"Verify that missing required fields like 'name' or 'price' trigger appropriate validation errors.\",\n dependsOn: []\n }\n ]\n },\n {\n method: \"patch\",\n path: \"/shopping/products/{productId}\",\n plans: [\n {\n draft: \"Attempt to update a product with an invalid productId and expect a 404 error.\",\n dependsOn: []\n }\n ]\n }\n]\n```\n\n- Each top-level object is a **plan group** for a single unique endpoint (`method + path`).\n- The `plans` array contains **one or more test drafts** for that endpoint.\n- Each `draft` may list its **prerequisite API calls** in the `dependsOn` array, which includes `method`, `path`, and a `purpose` for context.\n\n---\n\n### \u2705 **Uniqueness Rule**\n\n> \u26A0\uFE0F **Each `{method} + {path}` combination must appear only once** in the output array.\n> This means **you must not create multiple plan groups with the same HTTP method and path.**\n\n* Treat each `{method} + {path}` pair as a **unique test identifier**.\n* All test plans (`plans`) related to the same endpoint must be **grouped under a single PlanGroup object**.\n* Duplicating PlanGroups for the same endpoint will lead to invalid output.\n\n**\u2705 Good:**\n\n```ts\n[\n {\n method: \"patch\",\n path: \"/blog/posts/{postId}\",\n plans: [\n { draft: \"...\", dependsOn: [...] },\n { draft: \"...\", dependsOn: [...] }\n ]\n }\n]\n```\n\n**\u274C Bad:**\n\n```ts\n[\n {\n method: \"patch\",\n path: \"/blog/posts/{postId}\",\n plans: [ ... ]\n },\n {\n method: \"patch\",\n path: \"/blog/posts/{postId}\", // Duplicate! Not allowed.\n plans: [ ... ]\n }\n]\n```\n\n---\n\n## Writing Guidelines\n\n1. **draft**:\n - Write a clear and realistic test plan for the operation.\n - Include both success and failure cases where applicable.\n - Incorporate constraints mentioned in the API description such as uniqueness, foreign key requirements, or authentication.\n - For complex operations, include multiple steps within the same `draft` string (e.g., create \u2192 verify \u2192 delete).\n\n2. **dependsOn**:\n - List other API operations that must be invoked before this test can be executed.\n - Each item must include `method`, `path`, and `purpose`.\n - The `purpose` field should explain *why* the dependency is needed in the test setup.\n\n3. Treat each `{method} + {path}` combination as a unique test identifier.\n\n---\n\n## Purpose\n\nThese test scenario objects are designed to support QA engineers and backend developers in planning automated or manual tests. Each test draft reflects the core functionality and business rules of the API to ensure robust system behavior." /* AutoBeSystemPromptConstant.TEST_SCENARIO */,
130
+ text: "# API Test Scenario Generator AI Agent System Prompt\n\n## 1. Overview\n\nYou are a specialized AI Agent for generating comprehensive API test scenarios based on provided API operation definitions. Your core mission is to analyze API endpoints and create realistic, business-logic-focused test scenario drafts that will later be used by developers to implement actual E2E test functions.\n\n\nYou will receive an array of API operation objects along with their specifications, descriptions, and parameters. Based on these materials, you must generate structured test scenario groups that encompass both success and failure cases, considering real-world business constraints and user workflows.\n\nYour role is **scenario planning**. You must think like a QA engineer who understands business logic and user journeys, creating comprehensive test plans that cover edge cases, validation rules, and complex multi-step processes.\n\nThe final deliverable must be a structured output containing scenario groups with detailed test drafts, dependency mappings, and clear function naming that reflects user-centric perspectives.\n\n## 2. Input Material Composition\n\n### 2.1. API Operations Array\n\n* Complete API operation definitions with summary, method and path\n* Business logic descriptions and constraints embedded in summary\n\n**Deep Analysis Requirements:**\n\n* **Business Domain Understanding**: Identify the business domain (e-commerce, content management, user authentication, etc.) and understand typical user workflows\n* **Entity Relationship Discovery**: Map relationships between different entities (users, products, orders, reviews, etc.) and understand their dependencies\n* **Workflow Pattern Recognition**: Identify common patterns like CRUD operations, authentication flows, approval processes, and multi-step transactions\n* **Constraint and Validation Rule Extraction**: Extract business rules, validation constraints, uniqueness requirements, and permission-based access controls\n* **User Journey Mapping**: Understand complete user journeys that span multiple API calls and identify realistic test scenarios\n\n### 2.2. Include/Exclude Lists\n\n* **Include List**: API endpoints that must be covered in the test scenarios being generated. These are the primary targets of the current test generation.\n* **Exclude List**: Endpoints that do not require new test scenarios in this iteration. However, these endpoints may still be referenced as **dependencies** in the scenario drafts if the current tests logically depend on their outcomes or data.\n\n**Deep Analysis Requirements:**\n\n* **Dependency Identification**: Understand which excluded endpoints can serve as prerequisites for included endpoints\n* **Coverage Gap Analysis**: Ensure all included endpoints have comprehensive test coverage without redundancy\n* **Cross-Reference Mapping**: Map relationships between included endpoints and available excluded endpoints for dependency planning\n\n## 3. Core Scenario Generation Principles\n\n### 3.1. Business Logic Focus Principle\n\n* **Real-World Scenarios**: Generate scenarios that reflect actual user workflows and business processes\n* **End-to-End Thinking**: Consider complete user journeys that may span multiple API calls\n* **Business Rule Validation**: Include scenarios that test business constraints, validation rules, and edge cases\n* **User Perspective**: Write scenarios from the user's perspective, focusing on what users are trying to accomplish\n\n### 3.2. Comprehensive Coverage Principle\n\n* **Success Path Coverage**: Ensure all primary business functions are covered with successful execution scenarios\n* **Failure Path Coverage**: Include validation failures, permission errors, resource not found cases, and business rule violations\n* **Edge Case Identification**: Consider boundary conditions, race conditions, and unusual but valid user behaviors\n* **State Transition Testing**: Test different states of entities and valid/invalid state transitions\n\n### 3.3. Dependency Management Principle\n\n* **Prerequisite Identification**: Clearly identify all API calls that must precede the target operation (only when explicitly required)\n* **Data Setup Requirements**: Understand what data must exist before testing specific scenarios\n* **Authentication Context**: Include necessary authentication and authorization setup steps\n* **Logical Ordering**: Ensure dependencies are listed in the correct execution order if step-by-step execution is required\n\n> \u26A0\uFE0F **Note**: The `dependencies` field in a scenario is not a sequential execution plan. It is an indicative reference to other endpoints that this scenario relies on for logical or data setup context. If execution order is relevant, describe it explicitly in the `purpose` field of each dependency.\n\n### 3.4. Realistic Scenario Principle\n\n* **Authentic User Stories**: Create scenarios that represent real user needs and workflows\n* **Business Context Integration**: Embed scenarios within realistic business contexts (e.g., e-commerce purchase flows, content publication workflows)\n* **Multi-Step Process Modeling**: Model complex business processes that require multiple coordinated API calls\n* **Error Recovery Scenarios**: Include scenarios for how users recover from errors or complete alternative workflows\n\n### 3.5. Clear Communication Principle\n\n* **Descriptive Draft Writing**: Write clear, detailed scenario descriptions that developers can easily understand and implement\n* **Function Naming Clarity**: Create function names that immediately convey the user scenario being tested\n* **Dependency Purpose Explanation**: Clearly explain why each dependency is necessary for the test scenario\n* **Business Justification**: Explain the business value and importance of each test scenario\n\n## 4. Detailed Scenario Generation Guidelines\n\n### 4.1. API Analysis Methodology\n\n* **Domain Context Discovery**: Identify the business domain and understand typical user workflows within that domain\n* **Entity Relationship Mapping**: Map relationships between different entities and understand their lifecycle dependencies\n* **Permission Model Understanding**: Understand user roles, permissions, and access control patterns\n* **Business Process Identification**: Identify multi-step business processes that span multiple API endpoints\n* **Validation Rule Extraction**: Extract all validation rules, constraints, and business logic from API specifications\n\n### 4.2. Scenario Draft Structure\n\nEach scenario draft should include:\n\n* **Context Setting**: Brief explanation of the business context and user motivation\n* **Step-by-Step Process**: Detailed description of the testing process, including all necessary steps\n* **Expected Outcomes**: Clear description of what should happen in both success and failure cases\n* **Business Rule Validation**: Specific business rules or constraints being tested\n* **Data Requirements**: What data needs to be prepared or validated during testing\n\n### 4.3. Function Naming Guidelines\n\nFollow the user-centric naming convention:\n\n* **Prefix**: Must start with `test_`\n* **User Action**: Primary action the user is performing (create, get, update, delete, search, etc.)\n* **Target Resource**: What the user is interacting with (user, product, order, review, etc.)\n* **Scenario Context**: Specific situation or condition (valid\\_data, invalid\\_email, not\\_found, permission\\_denied, etc.)\n\n**Examples:**\n\n* `test_create_product_with_valid_data`\n* `test_update_product_price_without_permission`\n* `test_search_products_with_empty_results`\n* `test_delete_product_that_does_not_exist`\n\n### 4.4. Dependency Identification Process\n\n* **Prerequisite Data Creation**: Identify what entities must be created before testing the target endpoint\n* **Authentication Setup**: Determine necessary authentication and authorization steps\n* **State Preparation**: Understand what system state must be established before testing\n* **Resource Relationship**: Map relationships between resources and identify dependent resource creation\n\n### 4.5. Multi-Scenario Planning\n\nFor complex endpoints, generate multiple scenarios covering:\n\n* **Happy Path**: Successful execution with valid data\n* **Validation Errors**: Various types of input validation failures\n* **Permission Errors**: Unauthorized access attempts\n* **Resource State Errors**: Operations on resources in invalid states\n* **Business Rule Violations**: Attempts to violate domain-specific business rules\n\n## 5. Dependency Purpose Guidelines\n\n* **The `dependencies` array refers to relevant API calls this scenario logically depends on, whether or not they are in the include list.**\n* **The presence of a dependency does not imply that it must be executed immediately beforehand.**\n* **Execution order, if required, should be explained in the `purpose`.**\n\nExample:\n\n```yaml\n dependencies:\n - endpoint: { method: \"post\", path: \"/posts\" }\n functionName: \"test_create_post_with_valid_data\"\n purpose: \"Create a post and extract postId for use in voting scenario\"\n```\n\n## 6. Error Scenario Guidelines\n\n### 6.1. Purpose and Importance of Error Scenarios\n\nTest scenarios must cover not only successful business flows but also various error conditions to ensure robust system behavior. Error scenarios help verify that appropriate responses are returned for invalid inputs, unauthorized access, resource conflicts, and business rule violations.\n\n### 6.2. Error Scenario Categories\n\n* **Validation Errors**: Invalid input data, missing required fields, format violations\n* **Authentication/Authorization Errors**: Unauthorized access, insufficient permissions, expired sessions\n* **Resource State Errors**: Operations on non-existent resources, invalid state transitions\n* **Business Rule Violations**: Attempts to violate domain-specific constraints and rules\n* **System Constraint Violations**: Duplicate resource creation, referential integrity violations\n\n### 6.3. Error Scenario Writing Guidelines\n\n* **Specific Error Conditions**: Clearly define the error condition being tested\n* **Expected Error Response**: Specify what type of error response should be returned\n* **Realistic Error Situations**: Model error conditions that actually occur in real usage\n* **Recovery Scenarios**: Consider how users might recover from or handle error conditions\n\n\n### 6.4. Error Scenario Example\n\n```typescript\n{\n draft: \"Test product creation failure caused by attempting to create a product with a duplicate SKU. First, create a seller account authorized to create products. Then, create an initial product with a specific SKU to set up the conflict condition. Finally, attempt to create another product with the same SKU and verify that the system returns a conflict error indicating SKU uniqueness violation. Note that these steps must be executed in order to properly simulate the scenario.\",\n functionName: \"test_create_product_with_duplicate_sku\",\n dependencies: [\n {\n endpoint: { method: \"post\", path: \"/shopping/sellers/auth/join\" },\n purpose: \"Create a seller account with permission to create products. This must be done first to ensure proper authorization.\"\n },\n {\n endpoint: { method: \"post\", path: \"/shopping/sellers/sales\" },\n purpose: \"Create the first product with a specific SKU to establish the conflict condition. This must be done after seller creation.\"\n }\n ]\n}\n````\n\n---\n\n**Additional Notes:**\n\n* It is critical to explicitly declare *all* prerequisite API calls necessary to prepare the test context within the `dependencies` array.\n* Dependencies represent logical requirements for the scenario and may or may not require strict execution order.\n* When there *is* a required sequence, such as creating a user before creating a product tied to that user, you **must** clearly indicate this order either in the scenario\u2019s `draft` description or in the `purpose` explanation of each dependency.\n* This explicit approach prevents using placeholder or fake data (like dummy UUIDs) and instead ensures that all data setup is conducted via real API calls, increasing test reliability and maintainability.\n* Providing clear and detailed `draft` text describing the full user workflow and error expectations helps downstream agents or developers generate complete and realistic test implementations.\n\nBy following these guidelines, generated test scenarios will be comprehensive, accurate, and fully grounded in the actual API ecosystem and business logic.\n\n\n\n\n## 7. Final Checklist\n\n### 7.1. Essential Element Verification\n\n* [ ] Are all included endpoints covered with appropriate scenarios?\n* [ ] Do scenarios reflect realistic business workflows and user journeys?\n* [ ] Are function names descriptive and follow the user-centric naming convention?\n* [ ] Are all necessary dependencies identified and properly ordered?\n* [ ] Do dependency purposes clearly explain why each prerequisite is needed?\n* [ ] Are both success and failure scenarios included for complex operations?\n* [ ] Do scenarios test relevant business rules and validation constraints?\n\n### 7.2. Quality Element Verification\n\n* [ ] Are scenario descriptions detailed enough for developers to implement?\n* [ ] Do scenarios represent authentic user needs and workflows?\n* [ ] Is the business context clearly explained for each scenario?\n* [ ] Are error scenarios realistic and cover important failure conditions?\n* [ ] Do multi-step scenarios include all necessary intermediate steps?\n* [ ] Are scenarios grouped logically by endpoint and functionality?\n\n### 7.3. Structural Verification\n\n* [ ] Does the output follow the correct IAutoBeTestScenarioApplication.IProps structure?\n* [ ] Are all endpoint objects properly formatted with method and path?\n* [ ] Do all scenarios include required fields (draft, functionName, dependencies)?\n* [ ] Are dependency objects complete with endpoint and purpose information?\n* [ ] Is each endpoint method/path combination unique in the scenario groups?\n\n## 7. Quality Standards\n\n### 7.1. Completeness\n- **Comprehensive Coverage**: All included endpoints have appropriate test scenarios\n- **Multi-Perspective Testing**: Include scenarios from different user roles and perspectives\n- **Edge Case Inclusion**: Cover boundary conditions, error cases, and unusual but valid scenarios\n- **Business Rule Coverage**: Test all relevant business rules and constraints\n\n### 7.2. Clarity and Usability\n- **Clear Scenario Descriptions**: Write scenarios that developers can easily understand and implement\n- **Logical Dependency Ordering**: List dependencies in the correct execution order\n- **Meaningful Function Names**: Create function names that clearly convey the test purpose\n- **Business Context**: Provide sufficient business context for understanding scenario importance\n\n### 7.3. Realistic Applicability\n- **Real-World Relevance**: Generate scenarios that reflect actual user workflows and business needs\n- **Implementation Feasibility**: Ensure scenarios can be realistically implemented using available APIs\n- **Business Value**: Focus on scenarios that test important business functionality\n- **User-Centric Design**: Write scenarios from the user's perspective and goals\n\n## 8. Error Scenario Generation (Appendix)\n\n### 8.1. Purpose and Importance of Error Scenarios\nTest scenarios must cover not only successful business flows but also various error conditions to ensure robust system behavior. Error scenarios help verify that appropriate responses are returned for invalid inputs, unauthorized access, resource conflicts, and business rule violations.\n\n### 8.2. Error Scenario Categories\n- **Validation Errors**: Invalid input data, missing required fields, format violations\n- **Authentication/Authorization Errors**: Unauthorized access, insufficient permissions, expired sessions\n- **Resource State Errors**: Operations on non-existent resources, invalid state transitions\n- **Business Rule Violations**: Attempts to violate domain-specific constraints and rules\n- **System Constraint Violations**: Duplicate resource creation, referential integrity violations\n\n### 8.3. Error Scenario Writing Guidelines\n- **Specific Error Conditions**: Clearly define the error condition being tested\n- **Expected Error Response**: Specify what type of error response should be returned\n- **Realistic Error Situations**: Model error conditions that actually occur in real usage\n- **Recovery Scenarios**: Consider how users might recover from or handle error conditions\n\n### 8.4. Error Scenario Example\n```typescript\n{\n draft: \"Test product creation failure when attempting to create a product with a duplicate SKU. Create an initial product with a specific SKU, then attempt to create another product with the same SKU. Verify that the system returns a conflict error indicating SKU uniqueness violation.\",\n functionName: \"test_create_product_with_duplicate_sku\",\n dependencies: [\n {\n endpoint: { method: \"post\", path: \"/shopping/sellers/auth/join\" },\n purpose: \"Create a seller account with permission to create products\"\n },\n {\n endpoint: { method: \"post\", path: \"/shopping/sellers/sales\" },\n purpose: \"Create the first product with a specific SKU to establish the conflict condition\"\n }\n ]\n}\n```\n\n## 9. Final Checklist\n\nTest scenario generation completion requires verification of the following items:\n\n### 9.1. Essential Element Verification\n- [ ] Are all included endpoints covered with appropriate scenarios?\n- [ ] Do scenarios reflect realistic business workflows and user journeys?\n- [ ] Are function names descriptive and follow the user-centric naming convention?\n- [ ] Are all necessary dependencies identified and properly ordered?\n- [ ] Do dependency purposes clearly explain why each prerequisite is needed?\n- [ ] Are both success and failure scenarios included for complex operations?\n- [ ] Do scenarios test relevant business rules and validation constraints?\n\n### 9.2. Quality Element Verification\n- [ ] Are scenario descriptions detailed enough for developers to implement?\n- [ ] Do scenarios represent authentic user needs and workflows?\n- [ ] Is the business context clearly explained for each scenario?\n- [ ] Are error scenarios realistic and cover important failure conditions?\n- [ ] Do multi-step scenarios include all necessary intermediate steps?\n- [ ] Are scenarios grouped logically by endpoint and functionality?\n\n### 9.3. Structural Verification\n- [ ] Does the output follow the correct IAutoBeTestScenarioApplication.IProps structure?\n- [ ] Are all endpoint objects properly formatted with method and path?\n- [ ] Do all scenarios include required fields (draft, functionName, dependencies)?\n- [ ] Are dependency objects complete with endpoint and purpose information?\n- [ ] Is each endpoint method/path combination unique in the scenario groups?\n\nPlease adhere to all these principles and guidelines to generate comprehensive and accurate API test scenarios. Your mission is to create scenario blueprints that enable developers to build robust, business-focused E2E test suites that thoroughly validate API functionality and business logic." /* AutoBeSystemPromptConstant.TEST_SCENARIO */,
131
131
  },
132
132
  {
133
133
  id: (0, uuid_1.v4)(),
134
134
  created_at: new Date().toISOString(),
135
135
  type: "systemMessage",
136
136
  text: [
137
+ "# Operations",
137
138
  "Below are the full operations. Please refer to this.",
138
139
  "Your role is to draft all test cases for each given Operation.",
139
140
  "It is also permissible to write multiple test codes on a single endpoint.",
140
141
  "However, rather than meaningless tests, business logic tests should be written and an E2E test situation should be assumed.",
141
142
  "",
143
+ "Please carefully analyze each operation to identify all dependencies required for testing.",
144
+ "For example, if you want to test liking and then deleting a post,",
145
+ "you might think to test post creation, liking, and unlike operations.",
146
+ "However, even if not explicitly mentioned, user registration and login are essential prerequisites.",
147
+ "Pay close attention to IDs and related values in the API,",
148
+ "and ensure you identify all dependencies between endpoints.",
149
+ "",
142
150
  "```json",
143
151
  JSON.stringify(operations.map((el) => ({
144
152
  path: el.path,
145
153
  method: el.method,
146
154
  summary: el.summary,
155
+ description: el.description,
156
+ parameters: el.parameters,
157
+ requestBody: el.requestBody,
158
+ responseBody: el.responseBody,
147
159
  }))),
148
160
  "```",
149
161
  ].join("\n"),
@@ -172,7 +184,7 @@ function createApplication(props) {
172
184
  (0, assertSchemaModel_1.assertSchemaModel)(props.model);
173
185
  const application = collection[props.model];
174
186
  application.functions[0].validate = (next) => {
175
- const result = (() => { const _io0 = input => Array.isArray(input.scenarioGroups) && input.scenarioGroups.every(elem => "object" === typeof elem && null !== elem && _io1(elem)); const _io1 = input => "object" === typeof input.endpoint && null !== input.endpoint && _io2(input.endpoint) && (Array.isArray(input.scenarios) && input.scenarios.every(elem => "object" === typeof elem && null !== elem && _io3(elem))); const _io2 = input => "string" === typeof input.path && ("get" === input.method || "post" === input.method || "put" === input.method || "delete" === input.method || "patch" === input.method); const _io3 = input => "string" === typeof input.draft && "string" === typeof input.functionName && (Array.isArray(input.dependsOn) && input.dependsOn.every(elem => "object" === typeof elem && null !== elem && _io4(elem))); const _io4 = input => "object" === typeof input.endpoint && null !== input.endpoint && _io2(input.endpoint) && "string" === typeof input.purpose; const _vo0 = (input, _path, _exceptionable = true) => [(Array.isArray(input.scenarioGroups) || _report(_exceptionable, {
187
+ const result = (() => { const _io0 = input => Array.isArray(input.scenarioGroups) && input.scenarioGroups.every(elem => "object" === typeof elem && null !== elem && _io1(elem)); const _io1 = input => "object" === typeof input.endpoint && null !== input.endpoint && _io2(input.endpoint) && (Array.isArray(input.scenarios) && input.scenarios.every(elem => "object" === typeof elem && null !== elem && _io3(elem))); const _io2 = input => "string" === typeof input.path && ("get" === input.method || "post" === input.method || "put" === input.method || "delete" === input.method || "patch" === input.method); const _io3 = input => "string" === typeof input.draft && "string" === typeof input.functionName && (Array.isArray(input.dependencies) && input.dependencies.every(elem => "object" === typeof elem && null !== elem && _io4(elem))); const _io4 = input => "object" === typeof input.endpoint && null !== input.endpoint && _io2(input.endpoint) && "string" === typeof input.purpose; const _vo0 = (input, _path, _exceptionable = true) => [(Array.isArray(input.scenarioGroups) || _report(_exceptionable, {
176
188
  path: _path + ".scenarioGroups",
177
189
  expected: "Array<IAutoBeTestScenarioApplication.IScenarioGroup>",
178
190
  value: input.scenarioGroups
@@ -228,22 +240,22 @@ function createApplication(props) {
228
240
  path: _path + ".functionName",
229
241
  expected: "string",
230
242
  value: input.functionName
231
- }), (Array.isArray(input.dependsOn) || _report(_exceptionable, {
232
- path: _path + ".dependsOn",
233
- expected: "Array<IAutoBeTestScenarioApplication.IDependsOn>",
234
- value: input.dependsOn
235
- })) && input.dependsOn.map((elem, _index6) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
236
- path: _path + ".dependsOn[" + _index6 + "]",
237
- expected: "IAutoBeTestScenarioApplication.IDependsOn",
243
+ }), (Array.isArray(input.dependencies) || _report(_exceptionable, {
244
+ path: _path + ".dependencies",
245
+ expected: "Array<IAutoBeTestScenarioApplication.IDependencies>",
246
+ value: input.dependencies
247
+ })) && input.dependencies.map((elem, _index6) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
248
+ path: _path + ".dependencies[" + _index6 + "]",
249
+ expected: "IAutoBeTestScenarioApplication.IDependencies",
238
250
  value: elem
239
- })) && _vo4(elem, _path + ".dependsOn[" + _index6 + "]", true && _exceptionable) || _report(_exceptionable, {
240
- path: _path + ".dependsOn[" + _index6 + "]",
241
- expected: "IAutoBeTestScenarioApplication.IDependsOn",
251
+ })) && _vo4(elem, _path + ".dependencies[" + _index6 + "]", true && _exceptionable) || _report(_exceptionable, {
252
+ path: _path + ".dependencies[" + _index6 + "]",
253
+ expected: "IAutoBeTestScenarioApplication.IDependencies",
242
254
  value: elem
243
255
  })).every(flag => flag) || _report(_exceptionable, {
244
- path: _path + ".dependsOn",
245
- expected: "Array<IAutoBeTestScenarioApplication.IDependsOn>",
246
- value: input.dependsOn
256
+ path: _path + ".dependencies",
257
+ expected: "Array<IAutoBeTestScenarioApplication.IDependencies>",
258
+ value: input.dependencies
247
259
  })].every(flag => flag); const _vo4 = (input, _path, _exceptionable = true) => [("object" === typeof input.endpoint && null !== input.endpoint || _report(_exceptionable, {
248
260
  path: _path + ".endpoint",
249
261
  expected: "AutoBeOpenApi.IEndpoint",
@@ -394,11 +406,11 @@ const claude = {
394
406
  description: "Array of test scenarios.",
395
407
  type: "array",
396
408
  items: {
397
- description: "Description of the current {@link IAutoBeTestScenarioApplication.IScenario} type:\n\n> Represents a test scenario for a single API operation.\n> \n> This interface extends `AutoBeOpenApi.IEndpoint`, inheriting its HTTP\n> method and path information, and adds two key properties:\n> \n> - `draft`: A free-form, human-readable test scenario description for the API\n> endpoint.\n> - `dependsOn`: A list of other API endpoints that must be invoked beforehand\n> in order to prepare the context for this test. Each dependency includes\n> the purpose of the dependency.\n> \n> This structure is intended to help organize test specifications for complex\n> workflows and ensure that all prerequisites are explicitly declared.",
409
+ description: "Description of the current {@link IAutoBeTestScenarioApplication.IScenario} type:\n\n> Represents a test scenario for a single API operation.\n> \n> This interface defines a structured, user-centric test draft that includes\n> a descriptive function name, a detailed scenario draft, and logical\n> dependencies on other endpoints required for context or setup.",
398
410
  type: "object",
399
411
  properties: {
400
412
  draft: {
401
- description: "A detailed natural language description of how this API endpoint should\nbe tested. This should include both successful and failure scenarios,\nbusiness rule validations, edge cases, and any sequence of steps\nnecessary to perform the test. A subsequent agent will use this draft to\ngenerate multiple test scenarios.",
413
+ description: "A detailed natural language description of how this API endpoint should\nbe tested. This should include both successful and failure scenarios,\nbusiness rule validations, edge cases, and any sequence of steps\nnecessary to perform the test. A subsequent agent will use this draft to\ngenerate multiple concrete test cases.",
402
414
  type: "string"
403
415
  },
404
416
  functionName: {
@@ -406,15 +418,16 @@ const claude = {
406
418
  description: "Descriptive function name derived from the user scenario.\n\nThe function name serves as a concise, technical identifier that clearly\nrepresents the specific user scenario being described. It should be\nimmediately understandable and directly correspond to the user situation\nwithout requiring additional context.\n\n## Naming Convention\n\n- Must start with `test_` prefix (mandatory requirement)\n- Use snake_case formatting throughout\n- Include the primary user action (create, get, update, delete, list, etc.)\n- Specify the target resource (user, product, order, profile, etc.)\n- Add scenario-specific context (valid_data, invalid_email, not_found,\n etc.)\n\n## Content Structure\n\nFunction names should follow this pattern:\n`test_[user_action]_[resource]_[scenario_context]`\n\nWhere:\n\n- `user_action`: What the user is trying to do\n- `resource`: What the user is interacting with\n- `scenario_context`: The specific situation or condition\n\n## User-Focused Examples\n\n- `test_create_user_profile_with_complete_information` - User providing all\n available profile data\n- `test_retrieve_user_profile_when_profile_exists` - User accessing their\n existing profile\n- `test_update_user_email_with_valid_new_address` - User changing their\n email to a valid new one\n- `test_delete_user_account_when_user_lacks_permission` - User attempting\n account deletion without authorization\n- `test_search_user_profiles_with_pagination_preferences` - User browsing\n profiles with specific pagination\n\n## Clarity Guidelines\n\n- Prioritize clarity over brevity\n- Avoid technical jargon or implementation terms\n- Use terminology that reflects user perspective\n- Ensure the name alone conveys the user's intent\n- Make it understandable to non-technical stakeholders\n- Keep consistent with user scenario description\n\n## Single Endpoint Alignment\n\nFunction names must reflect scenarios that:\n\n- Accomplish user goals through this single endpoint only\n- Don't imply dependency on other API operations\n- Represent complete user interactions",
407
419
  type: "string"
408
420
  },
409
- dependsOn: {
410
- description: "A list of other API endpoints that must be executed before this test\nscenario. This helps express dependencies such as data creation or\nauthentication steps required to reach the intended test state.",
421
+ dependencies: {
422
+ title: "A list of other API endpoints that this scenario logically depends on",
423
+ description: "A list of other API endpoints that this scenario logically depends on.\n\nThese dependencies represent context or prerequisite conditions, such as\nauthentication, resource creation, or data setup, that are relevant to\nthe test. This list is not a strict execution order \u2014 if ordering is\nimportant, it must be described explicitly in the `purpose`.",
411
424
  type: "array",
412
425
  items: {
413
- description: "Current Type: {@link IAutoBeTestScenarioApplication.IDependsOn}",
426
+ description: "Current Type: {@link IAutoBeTestScenarioApplication.IDependencies}",
414
427
  type: "object",
415
428
  properties: {
416
429
  endpoint: {
417
- description: "Target API endpoint that must be executed before the main operation.\n\n------------------------------\n\nDescription of the current {@link AutoBeOpenApi.IEndpoint} type:\n\n> API endpoint information.",
430
+ description: "Target API endpoint that this scenario depends on.\n\n------------------------------\n\nDescription of the current {@link AutoBeOpenApi.IEndpoint} type:\n\n> API endpoint information.",
418
431
  type: "object",
419
432
  properties: {
420
433
  path: {
@@ -450,7 +463,7 @@ const claude = {
450
463
  ]
451
464
  },
452
465
  purpose: {
453
- description: "A concise exscenarioation of why this API call is required before\nexecuting the test for the main operation.\n\nExample: \"Creates a category so that a product can be linked to it during\ncreation.\"",
466
+ description: "A concise explanation of why this API call is relevant or required for\nthe main test scenario.\n\nThis should describe the contextual or setup role of the dependency, such\nas creating necessary data or establishing user authentication.\n\nExample: \"Creates a category so that a product can be linked to it during\ncreation.\"",
454
467
  type: "string"
455
468
  }
456
469
  },
@@ -464,7 +477,7 @@ const claude = {
464
477
  required: [
465
478
  "draft",
466
479
  "functionName",
467
- "dependsOn"
480
+ "dependencies"
468
481
  ]
469
482
  }
470
483
  }
@@ -483,7 +496,7 @@ const claude = {
483
496
  $defs: {}
484
497
  },
485
498
  description: "Make test scenarios for the given endpoints.",
486
- validate: (() => { const _io0 = input => Array.isArray(input.scenarioGroups) && input.scenarioGroups.every(elem => "object" === typeof elem && null !== elem && _io1(elem)); const _io1 = input => "object" === typeof input.endpoint && null !== input.endpoint && _io2(input.endpoint) && (Array.isArray(input.scenarios) && input.scenarios.every(elem => "object" === typeof elem && null !== elem && _io3(elem))); const _io2 = input => "string" === typeof input.path && ("get" === input.method || "post" === input.method || "put" === input.method || "delete" === input.method || "patch" === input.method); const _io3 = input => "string" === typeof input.draft && "string" === typeof input.functionName && (Array.isArray(input.dependsOn) && input.dependsOn.every(elem => "object" === typeof elem && null !== elem && _io4(elem))); const _io4 = input => "object" === typeof input.endpoint && null !== input.endpoint && _io2(input.endpoint) && "string" === typeof input.purpose; const _vo0 = (input, _path, _exceptionable = true) => [(Array.isArray(input.scenarioGroups) || _report(_exceptionable, {
499
+ validate: (() => { const _io0 = input => Array.isArray(input.scenarioGroups) && input.scenarioGroups.every(elem => "object" === typeof elem && null !== elem && _io1(elem)); const _io1 = input => "object" === typeof input.endpoint && null !== input.endpoint && _io2(input.endpoint) && (Array.isArray(input.scenarios) && input.scenarios.every(elem => "object" === typeof elem && null !== elem && _io3(elem))); const _io2 = input => "string" === typeof input.path && ("get" === input.method || "post" === input.method || "put" === input.method || "delete" === input.method || "patch" === input.method); const _io3 = input => "string" === typeof input.draft && "string" === typeof input.functionName && (Array.isArray(input.dependencies) && input.dependencies.every(elem => "object" === typeof elem && null !== elem && _io4(elem))); const _io4 = input => "object" === typeof input.endpoint && null !== input.endpoint && _io2(input.endpoint) && "string" === typeof input.purpose; const _vo0 = (input, _path, _exceptionable = true) => [(Array.isArray(input.scenarioGroups) || _report(_exceptionable, {
487
500
  path: _path + ".scenarioGroups",
488
501
  expected: "Array<IAutoBeTestScenarioApplication.IScenarioGroup>",
489
502
  value: input.scenarioGroups
@@ -539,22 +552,22 @@ const claude = {
539
552
  path: _path + ".functionName",
540
553
  expected: "string",
541
554
  value: input.functionName
542
- }), (Array.isArray(input.dependsOn) || _report(_exceptionable, {
543
- path: _path + ".dependsOn",
544
- expected: "Array<IAutoBeTestScenarioApplication.IDependsOn>",
545
- value: input.dependsOn
546
- })) && input.dependsOn.map((elem, _index6) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
547
- path: _path + ".dependsOn[" + _index6 + "]",
548
- expected: "IAutoBeTestScenarioApplication.IDependsOn",
555
+ }), (Array.isArray(input.dependencies) || _report(_exceptionable, {
556
+ path: _path + ".dependencies",
557
+ expected: "Array<IAutoBeTestScenarioApplication.IDependencies>",
558
+ value: input.dependencies
559
+ })) && input.dependencies.map((elem, _index6) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
560
+ path: _path + ".dependencies[" + _index6 + "]",
561
+ expected: "IAutoBeTestScenarioApplication.IDependencies",
549
562
  value: elem
550
- })) && _vo4(elem, _path + ".dependsOn[" + _index6 + "]", true && _exceptionable) || _report(_exceptionable, {
551
- path: _path + ".dependsOn[" + _index6 + "]",
552
- expected: "IAutoBeTestScenarioApplication.IDependsOn",
563
+ })) && _vo4(elem, _path + ".dependencies[" + _index6 + "]", true && _exceptionable) || _report(_exceptionable, {
564
+ path: _path + ".dependencies[" + _index6 + "]",
565
+ expected: "IAutoBeTestScenarioApplication.IDependencies",
553
566
  value: elem
554
567
  })).every(flag => flag) || _report(_exceptionable, {
555
- path: _path + ".dependsOn",
556
- expected: "Array<IAutoBeTestScenarioApplication.IDependsOn>",
557
- value: input.dependsOn
568
+ path: _path + ".dependencies",
569
+ expected: "Array<IAutoBeTestScenarioApplication.IDependencies>",
570
+ value: input.dependencies
558
571
  })].every(flag => flag); const _vo4 = (input, _path, _exceptionable = true) => [("object" === typeof input.endpoint && null !== input.endpoint || _report(_exceptionable, {
559
572
  path: _path + ".endpoint",
560
573
  expected: "AutoBeOpenApi.IEndpoint",
@@ -653,11 +666,11 @@ const collection = {
653
666
  description: "Array of test scenarios.",
654
667
  type: "array",
655
668
  items: {
656
- description: "Description of the current {@link IAutoBeTestScenarioApplication.IScenario} type:\n\n> Represents a test scenario for a single API operation.\n> \n> This interface extends `AutoBeOpenApi.IEndpoint`, inheriting its HTTP\n> method and path information, and adds two key properties:\n> \n> - `draft`: A free-form, human-readable test scenario description for the API\n> endpoint.\n> - `dependsOn`: A list of other API endpoints that must be invoked beforehand\n> in order to prepare the context for this test. Each dependency includes\n> the purpose of the dependency.\n> \n> This structure is intended to help organize test specifications for complex\n> workflows and ensure that all prerequisites are explicitly declared.",
669
+ description: "Description of the current {@link IAutoBeTestScenarioApplication.IScenario} type:\n\n> Represents a test scenario for a single API operation.\n> \n> This interface defines a structured, user-centric test draft that includes\n> a descriptive function name, a detailed scenario draft, and logical\n> dependencies on other endpoints required for context or setup.",
657
670
  type: "object",
658
671
  properties: {
659
672
  draft: {
660
- description: "A detailed natural language description of how this API endpoint should\nbe tested. This should include both successful and failure scenarios,\nbusiness rule validations, edge cases, and any sequence of steps\nnecessary to perform the test. A subsequent agent will use this draft to\ngenerate multiple test scenarios.",
673
+ description: "A detailed natural language description of how this API endpoint should\nbe tested. This should include both successful and failure scenarios,\nbusiness rule validations, edge cases, and any sequence of steps\nnecessary to perform the test. A subsequent agent will use this draft to\ngenerate multiple concrete test cases.",
661
674
  type: "string"
662
675
  },
663
676
  functionName: {
@@ -665,15 +678,16 @@ const collection = {
665
678
  description: "Descriptive function name derived from the user scenario.\n\nThe function name serves as a concise, technical identifier that clearly\nrepresents the specific user scenario being described. It should be\nimmediately understandable and directly correspond to the user situation\nwithout requiring additional context.\n\n## Naming Convention\n\n- Must start with `test_` prefix (mandatory requirement)\n- Use snake_case formatting throughout\n- Include the primary user action (create, get, update, delete, list, etc.)\n- Specify the target resource (user, product, order, profile, etc.)\n- Add scenario-specific context (valid_data, invalid_email, not_found,\n etc.)\n\n## Content Structure\n\nFunction names should follow this pattern:\n`test_[user_action]_[resource]_[scenario_context]`\n\nWhere:\n\n- `user_action`: What the user is trying to do\n- `resource`: What the user is interacting with\n- `scenario_context`: The specific situation or condition\n\n## User-Focused Examples\n\n- `test_create_user_profile_with_complete_information` - User providing all\n available profile data\n- `test_retrieve_user_profile_when_profile_exists` - User accessing their\n existing profile\n- `test_update_user_email_with_valid_new_address` - User changing their\n email to a valid new one\n- `test_delete_user_account_when_user_lacks_permission` - User attempting\n account deletion without authorization\n- `test_search_user_profiles_with_pagination_preferences` - User browsing\n profiles with specific pagination\n\n## Clarity Guidelines\n\n- Prioritize clarity over brevity\n- Avoid technical jargon or implementation terms\n- Use terminology that reflects user perspective\n- Ensure the name alone conveys the user's intent\n- Make it understandable to non-technical stakeholders\n- Keep consistent with user scenario description\n\n## Single Endpoint Alignment\n\nFunction names must reflect scenarios that:\n\n- Accomplish user goals through this single endpoint only\n- Don't imply dependency on other API operations\n- Represent complete user interactions",
666
679
  type: "string"
667
680
  },
668
- dependsOn: {
669
- description: "A list of other API endpoints that must be executed before this test\nscenario. This helps express dependencies such as data creation or\nauthentication steps required to reach the intended test state.",
681
+ dependencies: {
682
+ title: "A list of other API endpoints that this scenario logically depends on",
683
+ description: "A list of other API endpoints that this scenario logically depends on.\n\nThese dependencies represent context or prerequisite conditions, such as\nauthentication, resource creation, or data setup, that are relevant to\nthe test. This list is not a strict execution order \u2014 if ordering is\nimportant, it must be described explicitly in the `purpose`.",
670
684
  type: "array",
671
685
  items: {
672
- description: "Current Type: {@link IAutoBeTestScenarioApplication.IDependsOn}",
686
+ description: "Current Type: {@link IAutoBeTestScenarioApplication.IDependencies}",
673
687
  type: "object",
674
688
  properties: {
675
689
  endpoint: {
676
- description: "Target API endpoint that must be executed before the main operation.\n\n------------------------------\n\nDescription of the current {@link AutoBeOpenApi.IEndpoint} type:\n\n> API endpoint information.",
690
+ description: "Target API endpoint that this scenario depends on.\n\n------------------------------\n\nDescription of the current {@link AutoBeOpenApi.IEndpoint} type:\n\n> API endpoint information.",
677
691
  type: "object",
678
692
  properties: {
679
693
  path: {
@@ -700,7 +714,7 @@ const collection = {
700
714
  ]
701
715
  },
702
716
  purpose: {
703
- description: "A concise exscenarioation of why this API call is required before\nexecuting the test for the main operation.\n\nExample: \"Creates a category so that a product can be linked to it during\ncreation.\"",
717
+ description: "A concise explanation of why this API call is relevant or required for\nthe main test scenario.\n\nThis should describe the contextual or setup role of the dependency, such\nas creating necessary data or establishing user authentication.\n\nExample: \"Creates a category so that a product can be linked to it during\ncreation.\"",
704
718
  type: "string"
705
719
  }
706
720
  },
@@ -714,7 +728,7 @@ const collection = {
714
728
  required: [
715
729
  "draft",
716
730
  "functionName",
717
- "dependsOn"
731
+ "dependencies"
718
732
  ]
719
733
  }
720
734
  }
@@ -733,7 +747,7 @@ const collection = {
733
747
  $defs: {}
734
748
  },
735
749
  description: "Make test scenarios for the given endpoints.",
736
- validate: (() => { const _io0 = input => Array.isArray(input.scenarioGroups) && input.scenarioGroups.every(elem => "object" === typeof elem && null !== elem && _io1(elem)); const _io1 = input => "object" === typeof input.endpoint && null !== input.endpoint && _io2(input.endpoint) && (Array.isArray(input.scenarios) && input.scenarios.every(elem => "object" === typeof elem && null !== elem && _io3(elem))); const _io2 = input => "string" === typeof input.path && ("get" === input.method || "post" === input.method || "put" === input.method || "delete" === input.method || "patch" === input.method); const _io3 = input => "string" === typeof input.draft && "string" === typeof input.functionName && (Array.isArray(input.dependsOn) && input.dependsOn.every(elem => "object" === typeof elem && null !== elem && _io4(elem))); const _io4 = input => "object" === typeof input.endpoint && null !== input.endpoint && _io2(input.endpoint) && "string" === typeof input.purpose; const _vo0 = (input, _path, _exceptionable = true) => [(Array.isArray(input.scenarioGroups) || _report(_exceptionable, {
750
+ validate: (() => { const _io0 = input => Array.isArray(input.scenarioGroups) && input.scenarioGroups.every(elem => "object" === typeof elem && null !== elem && _io1(elem)); const _io1 = input => "object" === typeof input.endpoint && null !== input.endpoint && _io2(input.endpoint) && (Array.isArray(input.scenarios) && input.scenarios.every(elem => "object" === typeof elem && null !== elem && _io3(elem))); const _io2 = input => "string" === typeof input.path && ("get" === input.method || "post" === input.method || "put" === input.method || "delete" === input.method || "patch" === input.method); const _io3 = input => "string" === typeof input.draft && "string" === typeof input.functionName && (Array.isArray(input.dependencies) && input.dependencies.every(elem => "object" === typeof elem && null !== elem && _io4(elem))); const _io4 = input => "object" === typeof input.endpoint && null !== input.endpoint && _io2(input.endpoint) && "string" === typeof input.purpose; const _vo0 = (input, _path, _exceptionable = true) => [(Array.isArray(input.scenarioGroups) || _report(_exceptionable, {
737
751
  path: _path + ".scenarioGroups",
738
752
  expected: "Array<IAutoBeTestScenarioApplication.IScenarioGroup>",
739
753
  value: input.scenarioGroups
@@ -789,22 +803,22 @@ const collection = {
789
803
  path: _path + ".functionName",
790
804
  expected: "string",
791
805
  value: input.functionName
792
- }), (Array.isArray(input.dependsOn) || _report(_exceptionable, {
793
- path: _path + ".dependsOn",
794
- expected: "Array<IAutoBeTestScenarioApplication.IDependsOn>",
795
- value: input.dependsOn
796
- })) && input.dependsOn.map((elem, _index6) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
797
- path: _path + ".dependsOn[" + _index6 + "]",
798
- expected: "IAutoBeTestScenarioApplication.IDependsOn",
806
+ }), (Array.isArray(input.dependencies) || _report(_exceptionable, {
807
+ path: _path + ".dependencies",
808
+ expected: "Array<IAutoBeTestScenarioApplication.IDependencies>",
809
+ value: input.dependencies
810
+ })) && input.dependencies.map((elem, _index6) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
811
+ path: _path + ".dependencies[" + _index6 + "]",
812
+ expected: "IAutoBeTestScenarioApplication.IDependencies",
799
813
  value: elem
800
- })) && _vo4(elem, _path + ".dependsOn[" + _index6 + "]", true && _exceptionable) || _report(_exceptionable, {
801
- path: _path + ".dependsOn[" + _index6 + "]",
802
- expected: "IAutoBeTestScenarioApplication.IDependsOn",
814
+ })) && _vo4(elem, _path + ".dependencies[" + _index6 + "]", true && _exceptionable) || _report(_exceptionable, {
815
+ path: _path + ".dependencies[" + _index6 + "]",
816
+ expected: "IAutoBeTestScenarioApplication.IDependencies",
803
817
  value: elem
804
818
  })).every(flag => flag) || _report(_exceptionable, {
805
- path: _path + ".dependsOn",
806
- expected: "Array<IAutoBeTestScenarioApplication.IDependsOn>",
807
- value: input.dependsOn
819
+ path: _path + ".dependencies",
820
+ expected: "Array<IAutoBeTestScenarioApplication.IDependencies>",
821
+ value: input.dependencies
808
822
  })].every(flag => flag); const _vo4 = (input, _path, _exceptionable = true) => [("object" === typeof input.endpoint && null !== input.endpoint || _report(_exceptionable, {
809
823
  path: _path + ".endpoint",
810
824
  expected: "AutoBeOpenApi.IEndpoint",
@@ -905,14 +919,14 @@ const collection = {
905
919
  properties: {
906
920
  draft: {
907
921
  type: "string",
908
- description: "A detailed natural language description of how this API endpoint should\nbe tested. This should include both successful and failure scenarios,\nbusiness rule validations, edge cases, and any sequence of steps\nnecessary to perform the test. A subsequent agent will use this draft to\ngenerate multiple test scenarios."
922
+ description: "A detailed natural language description of how this API endpoint should\nbe tested. This should include both successful and failure scenarios,\nbusiness rule validations, edge cases, and any sequence of steps\nnecessary to perform the test. A subsequent agent will use this draft to\ngenerate multiple concrete test cases."
909
923
  },
910
924
  functionName: {
911
925
  type: "string",
912
926
  title: "Descriptive function name derived from the user scenario",
913
927
  description: "Descriptive function name derived from the user scenario.\n\nThe function name serves as a concise, technical identifier that clearly\nrepresents the specific user scenario being described. It should be\nimmediately understandable and directly correspond to the user situation\nwithout requiring additional context.\n\n## Naming Convention\n\n- Must start with `test_` prefix (mandatory requirement)\n- Use snake_case formatting throughout\n- Include the primary user action (create, get, update, delete, list, etc.)\n- Specify the target resource (user, product, order, profile, etc.)\n- Add scenario-specific context (valid_data, invalid_email, not_found,\n etc.)\n\n## Content Structure\n\nFunction names should follow this pattern:\n`test_[user_action]_[resource]_[scenario_context]`\n\nWhere:\n\n- `user_action`: What the user is trying to do\n- `resource`: What the user is interacting with\n- `scenario_context`: The specific situation or condition\n\n## User-Focused Examples\n\n- `test_create_user_profile_with_complete_information` - User providing all\n available profile data\n- `test_retrieve_user_profile_when_profile_exists` - User accessing their\n existing profile\n- `test_update_user_email_with_valid_new_address` - User changing their\n email to a valid new one\n- `test_delete_user_account_when_user_lacks_permission` - User attempting\n account deletion without authorization\n- `test_search_user_profiles_with_pagination_preferences` - User browsing\n profiles with specific pagination\n\n## Clarity Guidelines\n\n- Prioritize clarity over brevity\n- Avoid technical jargon or implementation terms\n- Use terminology that reflects user perspective\n- Ensure the name alone conveys the user's intent\n- Make it understandable to non-technical stakeholders\n- Keep consistent with user scenario description\n\n## Single Endpoint Alignment\n\nFunction names must reflect scenarios that:\n\n- Accomplish user goals through this single endpoint only\n- Don't imply dependency on other API operations\n- Represent complete user interactions"
914
928
  },
915
- dependsOn: {
929
+ dependencies: {
916
930
  type: "array",
917
931
  items: {
918
932
  type: "object",
@@ -942,30 +956,31 @@ const collection = {
942
956
  "path",
943
957
  "method"
944
958
  ],
945
- description: "Target API endpoint that must be executed before the main operation.\n\n------------------------------\n\nDescription of the current {@link AutoBeOpenApi.IEndpoint} type:\n\n> API endpoint information.",
959
+ description: "Target API endpoint that this scenario depends on.\n\n------------------------------\n\nDescription of the current {@link AutoBeOpenApi.IEndpoint} type:\n\n> API endpoint information.",
946
960
  additionalProperties: false
947
961
  },
948
962
  purpose: {
949
963
  type: "string",
950
- description: "A concise exscenarioation of why this API call is required before\nexecuting the test for the main operation.\n\nExample: \"Creates a category so that a product can be linked to it during\ncreation.\""
964
+ description: "A concise explanation of why this API call is relevant or required for\nthe main test scenario.\n\nThis should describe the contextual or setup role of the dependency, such\nas creating necessary data or establishing user authentication.\n\nExample: \"Creates a category so that a product can be linked to it during\ncreation.\""
951
965
  }
952
966
  },
953
967
  required: [
954
968
  "endpoint",
955
969
  "purpose"
956
970
  ],
957
- description: "Current Type: {@link IAutoBeTestScenarioApplication.IDependsOn}",
971
+ description: "Current Type: {@link IAutoBeTestScenarioApplication.IDependencies}",
958
972
  additionalProperties: false
959
973
  },
960
- description: "A list of other API endpoints that must be executed before this test\nscenario. This helps express dependencies such as data creation or\nauthentication steps required to reach the intended test state."
974
+ title: "A list of other API endpoints that this scenario logically depends on",
975
+ description: "A list of other API endpoints that this scenario logically depends on.\n\nThese dependencies represent context or prerequisite conditions, such as\nauthentication, resource creation, or data setup, that are relevant to\nthe test. This list is not a strict execution order \u2014 if ordering is\nimportant, it must be described explicitly in the `purpose`."
961
976
  }
962
977
  },
963
978
  required: [
964
979
  "draft",
965
980
  "functionName",
966
- "dependsOn"
981
+ "dependencies"
967
982
  ],
968
- description: "Description of the current {@link IAutoBeTestScenarioApplication.IScenario} type:\n\n> Represents a test scenario for a single API operation.\n> \n> This interface extends `AutoBeOpenApi.IEndpoint`, inheriting its HTTP\n> method and path information, and adds two key properties:\n> \n> - `draft`: A free-form, human-readable test scenario description for the API\n> endpoint.\n> - `dependsOn`: A list of other API endpoints that must be invoked beforehand\n> in order to prepare the context for this test. Each dependency includes\n> the purpose of the dependency.\n> \n> This structure is intended to help organize test specifications for complex\n> workflows and ensure that all prerequisites are explicitly declared.",
983
+ description: "Description of the current {@link IAutoBeTestScenarioApplication.IScenario} type:\n\n> Represents a test scenario for a single API operation.\n> \n> This interface defines a structured, user-centric test draft that includes\n> a descriptive function name, a detailed scenario draft, and logical\n> dependencies on other endpoints required for context or setup.",
969
984
  additionalProperties: false
970
985
  },
971
986
  title: "Array of test scenarios",
@@ -990,7 +1005,7 @@ const collection = {
990
1005
  additionalProperties: false
991
1006
  },
992
1007
  description: "Make test scenarios for the given endpoints.",
993
- validate: (() => { const _io0 = input => Array.isArray(input.scenarioGroups) && input.scenarioGroups.every(elem => "object" === typeof elem && null !== elem && _io1(elem)); const _io1 = input => "object" === typeof input.endpoint && null !== input.endpoint && _io2(input.endpoint) && (Array.isArray(input.scenarios) && input.scenarios.every(elem => "object" === typeof elem && null !== elem && _io3(elem))); const _io2 = input => "string" === typeof input.path && ("get" === input.method || "post" === input.method || "put" === input.method || "delete" === input.method || "patch" === input.method); const _io3 = input => "string" === typeof input.draft && "string" === typeof input.functionName && (Array.isArray(input.dependsOn) && input.dependsOn.every(elem => "object" === typeof elem && null !== elem && _io4(elem))); const _io4 = input => "object" === typeof input.endpoint && null !== input.endpoint && _io2(input.endpoint) && "string" === typeof input.purpose; const _vo0 = (input, _path, _exceptionable = true) => [(Array.isArray(input.scenarioGroups) || _report(_exceptionable, {
1008
+ validate: (() => { const _io0 = input => Array.isArray(input.scenarioGroups) && input.scenarioGroups.every(elem => "object" === typeof elem && null !== elem && _io1(elem)); const _io1 = input => "object" === typeof input.endpoint && null !== input.endpoint && _io2(input.endpoint) && (Array.isArray(input.scenarios) && input.scenarios.every(elem => "object" === typeof elem && null !== elem && _io3(elem))); const _io2 = input => "string" === typeof input.path && ("get" === input.method || "post" === input.method || "put" === input.method || "delete" === input.method || "patch" === input.method); const _io3 = input => "string" === typeof input.draft && "string" === typeof input.functionName && (Array.isArray(input.dependencies) && input.dependencies.every(elem => "object" === typeof elem && null !== elem && _io4(elem))); const _io4 = input => "object" === typeof input.endpoint && null !== input.endpoint && _io2(input.endpoint) && "string" === typeof input.purpose; const _vo0 = (input, _path, _exceptionable = true) => [(Array.isArray(input.scenarioGroups) || _report(_exceptionable, {
994
1009
  path: _path + ".scenarioGroups",
995
1010
  expected: "Array<IAutoBeTestScenarioApplication.IScenarioGroup>",
996
1011
  value: input.scenarioGroups
@@ -1046,22 +1061,22 @@ const collection = {
1046
1061
  path: _path + ".functionName",
1047
1062
  expected: "string",
1048
1063
  value: input.functionName
1049
- }), (Array.isArray(input.dependsOn) || _report(_exceptionable, {
1050
- path: _path + ".dependsOn",
1051
- expected: "Array<IAutoBeTestScenarioApplication.IDependsOn>",
1052
- value: input.dependsOn
1053
- })) && input.dependsOn.map((elem, _index6) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
1054
- path: _path + ".dependsOn[" + _index6 + "]",
1055
- expected: "IAutoBeTestScenarioApplication.IDependsOn",
1064
+ }), (Array.isArray(input.dependencies) || _report(_exceptionable, {
1065
+ path: _path + ".dependencies",
1066
+ expected: "Array<IAutoBeTestScenarioApplication.IDependencies>",
1067
+ value: input.dependencies
1068
+ })) && input.dependencies.map((elem, _index6) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
1069
+ path: _path + ".dependencies[" + _index6 + "]",
1070
+ expected: "IAutoBeTestScenarioApplication.IDependencies",
1056
1071
  value: elem
1057
- })) && _vo4(elem, _path + ".dependsOn[" + _index6 + "]", true && _exceptionable) || _report(_exceptionable, {
1058
- path: _path + ".dependsOn[" + _index6 + "]",
1059
- expected: "IAutoBeTestScenarioApplication.IDependsOn",
1072
+ })) && _vo4(elem, _path + ".dependencies[" + _index6 + "]", true && _exceptionable) || _report(_exceptionable, {
1073
+ path: _path + ".dependencies[" + _index6 + "]",
1074
+ expected: "IAutoBeTestScenarioApplication.IDependencies",
1060
1075
  value: elem
1061
1076
  })).every(flag => flag) || _report(_exceptionable, {
1062
- path: _path + ".dependsOn",
1063
- expected: "Array<IAutoBeTestScenarioApplication.IDependsOn>",
1064
- value: input.dependsOn
1077
+ path: _path + ".dependencies",
1078
+ expected: "Array<IAutoBeTestScenarioApplication.IDependencies>",
1079
+ value: input.dependencies
1065
1080
  })].every(flag => flag); const _vo4 = (input, _path, _exceptionable = true) => [("object" === typeof input.endpoint && null !== input.endpoint || _report(_exceptionable, {
1066
1081
  path: _path + ".endpoint",
1067
1082
  expected: "AutoBeOpenApi.IEndpoint",
@@ -1 +1 @@
1
- {"version":3,"file":"orchestrateTestScenario.js","sourceRoot":"","sources":["../../../src/orchestrate/test/orchestrateTestScenario.ts"],"names":[],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AAsBA,0DAyDC;;AA/ED,yCAIwB;AAQxB,kDAA0B;AAC1B,+BAA0B;AAI1B,uEAAoE;AACpE,yDAAsD;AACtD,iEAA8D;AAG9D,SAAsB,uBAAuB,CAC3C,GAAyB;;;QAEzB,MAAM,UAAU,GAAG,MAAA,MAAA,GAAG,CAAC,KAAK,EAAE,CAAC,SAAS,0CAAE,QAAQ,CAAC,UAAU,mCAAI,EAAE,CAAC;QACpE,IAAI,UAAU,CAAC,MAAM,KAAK,CAAC,EAAE,CAAC;YAC5B,MAAM,IAAI,KAAK,CACb,8DAA8D,CAC/D,CAAC;QACJ,CAAC;QAED,MAAM,OAAO,GAAoD,EAAE,CAAC;QACpE,IAAI,OAAO,GAA+B,KAAK,CAAC,IAAI,CAAC,UAAU,CAAC,CAAC;QAEjE,GAAG,CAAC;YACF,MAAM,MAAM,GAAG,IAAA,yBAAW,EAAC,EAAE,KAAK,EAAE,OAAO,EAAE,QAAQ,EAAE,EAAE,EAAE,CAAC,CAAC;YAE7D,MAAM,OAAO,CAAC,GAAG,CACf,MAAM,CAAC,GAAG,CAAC,CAAO,QAAQ,EAAE,EAAE;gBAC5B,OAAO,CAAC,IAAI,CACV,GAAG,CAAC,MAAM,OAAO,CACf,GAAG,EACH,UAAU,EACV,QAAQ,EACR,OAAO,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,QAAQ,CAAC,CAC/B,CAAC,CACH,CAAC;YACJ,CAAC,CAAA,CAAC,CACH,CAAC;YAEF,OAAO,GAAG,OAAO,CAAC,MAAM,CAAC,CAAC,EAAE,EAAE,EAAE;gBAC9B,IACE,OAAO,CAAC,IAAI,CACV,CAAC,EAAE,EAAE,EAAE,CACL,EAAE,CAAC,QAAQ,CAAC,MAAM,KAAK,EAAE,CAAC,MAAM,IAAI,EAAE,CAAC,QAAQ,CAAC,IAAI,KAAK,EAAE,CAAC,IAAI,CACnE,EACD,CAAC;oBACD,OAAO,KAAK,CAAC;gBACf,CAAC;gBACD,OAAO,IAAI,CAAC;YACd,CAAC,CAAC,CAAC;QACL,CAAC,QAAQ,OAAO,CAAC,MAAM,GAAG,CAAC,EAAE;QAE7B,OAAO;YACL,IAAI,EAAE,cAAc;YACpB,IAAI,EAAE,MAAA,MAAA,GAAG,CAAC,KAAK,EAAE,CAAC,OAAO,0CAAE,IAAI,mCAAI,CAAC;YACpC,SAAS,EAAE,OAAO,CAAC,OAAO,CAAC,CAAC,EAAE,EAAE,EAAE;gBAChC,OAAO,EAAE,CAAC,SAAS,CAAC,GAAG,CAAC,CAAC,IAAI,EAAE,EAAE;oBAC/B,OAAO;wBACL,QAAQ,EAAE,EAAE,CAAC,QAAQ;wBACrB,KAAK,EAAE,IAAI,CAAC,KAAK;wBACjB,YAAY,EAAE,IAAI,CAAC,YAAY;wBAC/B,YAAY,EAAE,IAAI,CAAC,SAAS;qBACA,CAAC;gBACjC,CAAC,CAAC,CAAC;YACL,CAAC,CAAC;YACF,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;SACV,CAAC;IAC/B,CAAC;CAAA;AAED,MAAM,OAAO,GAAG,CACd,GAAyB,EACzB,GAA+B,EAC/B,OAA4D,EAC5D,OAA4D,EAC5D,EAAE;;IACF,MAAM,OAAO,GAA8D;QACzE,KAAK,EAAE,EAAE;KACV,CAAC;IACF,MAAM,QAAQ,GAAyB,IAAI,oBAAa,CAAC;QACvD,KAAK,EAAE,GAAG,CAAC,KAAK;QAChB,MAAM,EAAE,GAAG,CAAC,MAAM;QAClB,MAAM,kCACD,CAAC,MAAA,GAAG,CAAC,MAAM,mCAAI,EAAE,CAAC,KACrB,QAAQ,EAAE;gBACR,QAAQ,EAAE,IAAI;aACf,GACF;QACD,UAAU,EAAE,GAAG,CAAC,KAAK,EAAE;QACvB,SAAS,EAAE,uBAAuB,CAAC,GAAG,EAAE,OAAO,EAAE,OAAO,CAAC;QACzD,WAAW,EAAE;YACX,iBAAiB,CAAC;gBAChB,KAAK,EAAE,GAAG,CAAC,KAAK;gBAChB,KAAK,EAAE,CAAC,IAAI,EAAE,EAAE;;oBACd,MAAA,OAAO,CAAC,KAAK,oCAAb,OAAO,CAAC,KAAK,GAAK,EAAE,EAAC;oBACrB,OAAO,CAAC,KAAK,CAAC,IAAI,CAAC,GAAG,IAAI,CAAC,cAAc,CAAC,CAAC;gBAC7C,CAAC;aACF,CAAC;SACH;KACF,CAAC,CAAC;IACH,IAAA,iCAAe,EAAC,QAAQ,CAAC,CAAC;IAE1B,MAAM,QAAQ,CAAC,UAAU,CAAC,wBAAwB,CAAC,CAAC;IACpD,IAAI,OAAO,CAAC,KAAK,CAAC,MAAM,KAAK,CAAC,EAAE,CAAC;QAC/B,MAAM,IAAI,KAAK,CAAC,8BAA8B,CAAC,CAAC;IAClD,CAAC;IAED,OAAO,OAAO,CAAC,KAAK,CAAC;AACvB,CAAC,CAAA,CAAC;AAEF,MAAM,uBAAuB,GAAG,CAC9B,UAAsC,EACtC,OAA4D,EAC5D,OAA4D,EAC5D,EAAE,CAAC;IACH;QACE,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;QACpC,IAAI,EAAE,eAAe;QACrB,IAAI,4yIAA0C;KACD;IAC/C;QACE,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;QACpC,IAAI,EAAE,eAAe;QACrB,IAAI,EAAE;YACJ,sDAAsD;YACtD,gEAAgE;YAChE,2EAA2E;YAC3E,6HAA6H;YAC7H,EAAE;YACF,SAAS;YACT,IAAI,CAAC,SAAS,CACZ,UAAU,CAAC,GAAG,CAAC,CAAC,EAAE,EAAE,EAAE,CAAC,CAAC;gBACtB,IAAI,EAAE,EAAE,CAAC,IAAI;gBACb,MAAM,EAAE,EAAE,CAAC,MAAM;gBACjB,OAAO,EAAE,EAAE,CAAC,OAAO;aACpB,CAAC,CAAC,CACJ;YACD,KAAK;SACN,CAAC,IAAI,CAAC,IAAI,CAAC;KACiC;IAC/C;QACE,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;QACpC,IAAI,EAAE,eAAe;QACrB,IAAI,EAAE;YACJ,yBAAyB;YACzB,OAAO;iBACJ,GAAG,CAAC,CAAC,EAAE,EAAE,EAAE,CAAC,KAAK,EAAE,CAAC,MAAM,CAAC,WAAW,EAAE,KAAK,EAAE,CAAC,IAAI,EAAE,CAAC;iBACvD,IAAI,CAAC,IAAI,CAAC;YACb,EAAE;YACF,2BAA2B;YAC3B,sGAAsG;YACtG,iDAAiD;YACjD,8GAA8G;YAC9G,OAAO;iBACJ,GAAG,CAAC,CAAC,EAAE,EAAE,EAAE,CAAC,KAAK,EAAE,CAAC,MAAM,CAAC,WAAW,EAAE,KAAK,EAAE,CAAC,IAAI,EAAE,CAAC;iBACvD,IAAI,CAAC,IAAI,CAAC;SACd,CAAC,IAAI,CAAC,IAAI,CAAC;KACiC;CAChD,CAAC;AAEF,SAAS,iBAAiB,CAAiC,KAG1D;IACC,IAAA,qCAAiB,EAAC,KAAK,CAAC,KAAK,CAAC,CAAC;IAE/B,MAAM,WAAW,GAA2B,UAAU,CACpD,KAAK,CAAC,KAAK,CACyB,CAAC;IAEvC,WAAW,CAAC,SAAS,CAAC,CAAC,CAAC,CAAC,QAAQ,GAAG,CAAC,IAAa,EAAe,EAAE;QACjE,MAAM,MAAM;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;gBAC4C,IAAI,CAAC,CAAC;QAC9D,IAAI,MAAM,CAAC,OAAO,KAAK,KAAK;YAAE,OAAO,MAAM,CAAC;QAE5C,MAAM,MAAM,GAAyB,EAAE,CAAC;QACxC,MAAM,CAAC,IAAI,CAAC,cAAc,CAAC,OAAO,CAAC,CAAC,EAAE,EAAE,CAAC,EAAE,GAAG,EAAE,EAAE;YAChD,GAAG,CAAC,OAAO,CAAC,CAAC,MAAM,EAAE,CAAC,EAAE,EAAE;gBACxB,IACE,CAAC,KAAK,CAAC;oBACP,MAAM,CAAC,QAAQ,CAAC,MAAM,KAAK,EAAE,CAAC,QAAQ,CAAC,MAAM;oBAC7C,MAAM,CAAC,QAAQ,CAAC,IAAI,KAAK,EAAE,CAAC,QAAQ,CAAC,IAAI,EACzC,CAAC;oBACD,IACE,CAAC,MAAM,CAAC,IAAI,CACV,CAAC,EAAE,EAAE,EAAE,CACL,EAAE,CAAC,IAAI,KAAK,cAAc,CAAC,QAAQ;wBACnC,EAAE,CAAC,KAAK,KAAK,MAAM,CAAC,QAAQ,CAAC,IAAI,CACpC,EACD,CAAC;wBACD,MAAM,CAAC,IAAI,CAAC;4BACV,IAAI,EAAE,cAAc,CAAC,QAAQ;4BAC7B,QAAQ,EAAE,gDAAgD;4BAC1D,KAAK,EAAE,MAAM,CAAC,QAAQ,CAAC,IAAI;yBAC5B,CAAC,CAAC;oBACL,CAAC;oBAED,IACE,CAAC,MAAM,CAAC,IAAI,CACV,CAAC,EAAE,EAAE,EAAE,CACL,EAAE,CAAC,IAAI,KAAK,cAAc,CAAC,UAAU;wBACrC,EAAE,CAAC,KAAK,KAAK,MAAM,CAAC,QAAQ,CAAC,MAAM,CACtC,EACD,CAAC;wBACD,MAAM,CAAC,IAAI,CAAC;4BACV,IAAI,EAAE,cAAc,CAAC,UAAU;4BAC/B,QAAQ,EAAE,gDAAgD;4BAC1D,KAAK,EAAE,MAAM,CAAC,QAAQ,CAAC,MAAM;yBAC9B,CAAC,CAAC;oBACL,CAAC;gBACH,CAAC;YACH,CAAC,CAAC,CAAC;QACL,CAAC,CAAC,CAAC;QAEH,IAAI,MAAM,CAAC,MAAM,KAAK,CAAC,EAAE,CAAC;YACxB,OAAO,CAAC,GAAG,CAAC,IAAI,CAAC,SAAS,CAAC,MAAM,EAAE,IAAI,EAAE,CAAC,CAAC,EAAE,QAAQ,CAAC,CAAC;YACvD,OAAO;gBACL,OAAO,EAAE,KAAK;gBACd,MAAM;gBACN,IAAI,EAAE,IAAI;aACX,CAAC;QACJ,CAAC;QAED,OAAO,MAAM,CAAC;IAChB,CAAC,CAAC;IACF,OAAO;QACL,QAAQ,EAAE,OAAO;QACjB,IAAI,EAAE,iBAAiB;QACvB,WAAW;QACX,OAAO,EAAE;YACP,YAAY,EAAE,CAAC,IAAI,EAAE,EAAE;gBACrB,KAAK,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC;YACpB,CAAC;SACuC;KAC3C,CAAC;AACJ,CAAC;AAED,MAAM,MAAM;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAMT,CAAC;AACJ,MAAM,UAAU,GAAG;IACjB,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;KAIJ;IACH,MAAM;IACN,KAAK,EAAE,MAAM;IACb,QAAQ,EAAE,MAAM;IAChB,KAAK,EAAE,MAAM;IACb,KAAK;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;KAAgE;CACtE,CAAC"}
1
+ {"version":3,"file":"orchestrateTestScenario.js","sourceRoot":"","sources":["../../../src/orchestrate/test/orchestrateTestScenario.ts"],"names":[],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AAsBA,0DAyDC;;AA/ED,yCAIwB;AAQxB,kDAA0B;AAC1B,+BAA0B;AAI1B,uEAAoE;AACpE,yDAAsD;AACtD,iEAA8D;AAG9D,SAAsB,uBAAuB,CAC3C,GAAyB;;;QAEzB,MAAM,UAAU,GAAG,MAAA,MAAA,GAAG,CAAC,KAAK,EAAE,CAAC,SAAS,0CAAE,QAAQ,CAAC,UAAU,mCAAI,EAAE,CAAC;QACpE,IAAI,UAAU,CAAC,MAAM,KAAK,CAAC,EAAE,CAAC;YAC5B,MAAM,IAAI,KAAK,CACb,8DAA8D,CAC/D,CAAC;QACJ,CAAC;QAED,MAAM,OAAO,GAAoD,EAAE,CAAC;QACpE,IAAI,OAAO,GAA+B,KAAK,CAAC,IAAI,CAAC,UAAU,CAAC,CAAC;QAEjE,GAAG,CAAC;YACF,MAAM,MAAM,GAAG,IAAA,yBAAW,EAAC,EAAE,KAAK,EAAE,OAAO,EAAE,QAAQ,EAAE,CAAC,EAAE,CAAC,CAAC;YAE5D,MAAM,OAAO,CAAC,GAAG,CACf,MAAM,CAAC,GAAG,CAAC,CAAO,QAAQ,EAAE,EAAE;gBAC5B,OAAO,CAAC,IAAI,CACV,GAAG,CAAC,MAAM,OAAO,CACf,GAAG,EACH,UAAU,EACV,QAAQ,EACR,OAAO,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,QAAQ,CAAC,CAC/B,CAAC,CACH,CAAC;YACJ,CAAC,CAAA,CAAC,CACH,CAAC;YAEF,OAAO,GAAG,OAAO,CAAC,MAAM,CAAC,CAAC,EAAE,EAAE,EAAE;gBAC9B,IACE,OAAO,CAAC,IAAI,CACV,CAAC,EAAE,EAAE,EAAE,CACL,EAAE,CAAC,QAAQ,CAAC,MAAM,KAAK,EAAE,CAAC,MAAM,IAAI,EAAE,CAAC,QAAQ,CAAC,IAAI,KAAK,EAAE,CAAC,IAAI,CACnE,EACD,CAAC;oBACD,OAAO,KAAK,CAAC;gBACf,CAAC;gBACD,OAAO,IAAI,CAAC;YACd,CAAC,CAAC,CAAC;QACL,CAAC,QAAQ,OAAO,CAAC,MAAM,GAAG,CAAC,EAAE;QAE7B,OAAO;YACL,IAAI,EAAE,cAAc;YACpB,IAAI,EAAE,MAAA,MAAA,GAAG,CAAC,KAAK,EAAE,CAAC,OAAO,0CAAE,IAAI,mCAAI,CAAC;YACpC,SAAS,EAAE,OAAO,CAAC,OAAO,CAAC,CAAC,EAAE,EAAE,EAAE;gBAChC,OAAO,EAAE,CAAC,SAAS,CAAC,GAAG,CAAC,CAAC,IAAI,EAAE,EAAE;oBAC/B,OAAO;wBACL,QAAQ,EAAE,EAAE,CAAC,QAAQ;wBACrB,KAAK,EAAE,IAAI,CAAC,KAAK;wBACjB,YAAY,EAAE,IAAI,CAAC,YAAY;wBAC/B,YAAY,EAAE,IAAI,CAAC,YAAY;qBACH,CAAC;gBACjC,CAAC,CAAC,CAAC;YACL,CAAC,CAAC;YACF,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;SACV,CAAC;IAC/B,CAAC;CAAA;AAED,MAAM,OAAO,GAAG,CACd,GAAyB,EACzB,GAA+B,EAC/B,OAA4D,EAC5D,OAA4D,EAC5D,EAAE;;IACF,MAAM,OAAO,GAA8D;QACzE,KAAK,EAAE,EAAE;KACV,CAAC;IACF,MAAM,QAAQ,GAAyB,IAAI,oBAAa,CAAC;QACvD,KAAK,EAAE,GAAG,CAAC,KAAK;QAChB,MAAM,EAAE,GAAG,CAAC,MAAM;QAClB,MAAM,kCACD,CAAC,MAAA,GAAG,CAAC,MAAM,mCAAI,EAAE,CAAC,KACrB,QAAQ,EAAE;gBACR,QAAQ,EAAE,IAAI;aACf,GACF;QACD,UAAU,EAAE,GAAG,CAAC,KAAK,EAAE;QACvB,SAAS,EAAE,uBAAuB,CAAC,GAAG,EAAE,OAAO,EAAE,OAAO,CAAC;QACzD,WAAW,EAAE;YACX,iBAAiB,CAAC;gBAChB,KAAK,EAAE,GAAG,CAAC,KAAK;gBAChB,KAAK,EAAE,CAAC,IAAI,EAAE,EAAE;;oBACd,MAAA,OAAO,CAAC,KAAK,oCAAb,OAAO,CAAC,KAAK,GAAK,EAAE,EAAC;oBACrB,OAAO,CAAC,KAAK,CAAC,IAAI,CAAC,GAAG,IAAI,CAAC,cAAc,CAAC,CAAC;gBAC7C,CAAC;aACF,CAAC;SACH;KACF,CAAC,CAAC;IACH,IAAA,iCAAe,EAAC,QAAQ,CAAC,CAAC;IAE1B,MAAM,QAAQ,CAAC,UAAU,CAAC,wBAAwB,CAAC,CAAC;IACpD,IAAI,OAAO,CAAC,KAAK,CAAC,MAAM,KAAK,CAAC,EAAE,CAAC;QAC/B,MAAM,IAAI,KAAK,CAAC,8BAA8B,CAAC,CAAC;IAClD,CAAC;IAED,OAAO,OAAO,CAAC,KAAK,CAAC;AACvB,CAAC,CAAA,CAAC;AAEF,MAAM,uBAAuB,GAAG,CAC9B,UAAsC,EACtC,OAA4D,EAC5D,OAA4D,EAG5D,EAAE,CAAC;IACH;QACE,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;QACpC,IAAI,EAAE,eAAe;QACrB,IAAI,gjmBAA0C;KACD;IAC/C;QACE,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;QACpC,IAAI,EAAE,eAAe;QACrB,IAAI,EAAE;YACJ,cAAc;YACd,sDAAsD;YACtD,gEAAgE;YAChE,2EAA2E;YAC3E,6HAA6H;YAC7H,EAAE;YACF,4FAA4F;YAC5F,mEAAmE;YACnE,uEAAuE;YACvE,qGAAqG;YACrG,2DAA2D;YAC3D,6DAA6D;YAC7D,EAAE;YACF,SAAS;YACT,IAAI,CAAC,SAAS,CACZ,UAAU,CAAC,GAAG,CAAC,CAAC,EAAE,EAAE,EAAE,CAAC,CAAC;gBACtB,IAAI,EAAE,EAAE,CAAC,IAAI;gBACb,MAAM,EAAE,EAAE,CAAC,MAAM;gBACjB,OAAO,EAAE,EAAE,CAAC,OAAO;gBACnB,WAAW,EAAE,EAAE,CAAC,WAAW;gBAC3B,UAAU,EAAE,EAAE,CAAC,UAAU;gBACzB,WAAW,EAAE,EAAE,CAAC,WAAW;gBAC3B,YAAY,EAAE,EAAE,CAAC,YAAY;aAC9B,CAAC,CAAC,CACJ;YACD,KAAK;SACN,CAAC,IAAI,CAAC,IAAI,CAAC;KACiC;IAC/C;QACE,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;QACpC,IAAI,EAAE,eAAe;QACrB,IAAI,EAAE;YACJ,yBAAyB;YACzB,OAAO;iBACJ,GAAG,CAAC,CAAC,EAAE,EAAE,EAAE,CAAC,KAAK,EAAE,CAAC,MAAM,CAAC,WAAW,EAAE,KAAK,EAAE,CAAC,IAAI,EAAE,CAAC;iBACvD,IAAI,CAAC,IAAI,CAAC;YACb,EAAE;YACF,2BAA2B;YAC3B,sGAAsG;YACtG,iDAAiD;YACjD,8GAA8G;YAC9G,OAAO;iBACJ,GAAG,CAAC,CAAC,EAAE,EAAE,EAAE,CAAC,KAAK,EAAE,CAAC,MAAM,CAAC,WAAW,EAAE,KAAK,EAAE,CAAC,IAAI,EAAE,CAAC;iBACvD,IAAI,CAAC,IAAI,CAAC;SACd,CAAC,IAAI,CAAC,IAAI,CAAC;KACiC;CAChD,CAAC;AAEF,SAAS,iBAAiB,CAAiC,KAG1D;IACC,IAAA,qCAAiB,EAAC,KAAK,CAAC,KAAK,CAAC,CAAC;IAE/B,MAAM,WAAW,GAA2B,UAAU,CACpD,KAAK,CAAC,KAAK,CACyB,CAAC;IAEvC,WAAW,CAAC,SAAS,CAAC,CAAC,CAAC,CAAC,QAAQ,GAAG,CAAC,IAAa,EAAe,EAAE;QACjE,MAAM,MAAM;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;gBAC4C,IAAI,CAAC,CAAC;QAC9D,IAAI,MAAM,CAAC,OAAO,KAAK,KAAK;YAAE,OAAO,MAAM,CAAC;QAE5C,MAAM,MAAM,GAAyB,EAAE,CAAC;QACxC,MAAM,CAAC,IAAI,CAAC,cAAc,CAAC,OAAO,CAAC,CAAC,EAAE,EAAE,CAAC,EAAE,GAAG,EAAE,EAAE;YAChD,GAAG,CAAC,OAAO,CAAC,CAAC,MAAM,EAAE,CAAC,EAAE,EAAE;gBACxB,IACE,CAAC,KAAK,CAAC;oBACP,MAAM,CAAC,QAAQ,CAAC,MAAM,KAAK,EAAE,CAAC,QAAQ,CAAC,MAAM;oBAC7C,MAAM,CAAC,QAAQ,CAAC,IAAI,KAAK,EAAE,CAAC,QAAQ,CAAC,IAAI,EACzC,CAAC;oBACD,IACE,CAAC,MAAM,CAAC,IAAI,CACV,CAAC,EAAE,EAAE,EAAE,CACL,EAAE,CAAC,IAAI,KAAK,cAAc,CAAC,QAAQ;wBACnC,EAAE,CAAC,KAAK,KAAK,MAAM,CAAC,QAAQ,CAAC,IAAI,CACpC,EACD,CAAC;wBACD,MAAM,CAAC,IAAI,CAAC;4BACV,IAAI,EAAE,cAAc,CAAC,QAAQ;4BAC7B,QAAQ,EAAE,gDAAgD;4BAC1D,KAAK,EAAE,MAAM,CAAC,QAAQ,CAAC,IAAI;yBAC5B,CAAC,CAAC;oBACL,CAAC;oBAED,IACE,CAAC,MAAM,CAAC,IAAI,CACV,CAAC,EAAE,EAAE,EAAE,CACL,EAAE,CAAC,IAAI,KAAK,cAAc,CAAC,UAAU;wBACrC,EAAE,CAAC,KAAK,KAAK,MAAM,CAAC,QAAQ,CAAC,MAAM,CACtC,EACD,CAAC;wBACD,MAAM,CAAC,IAAI,CAAC;4BACV,IAAI,EAAE,cAAc,CAAC,UAAU;4BAC/B,QAAQ,EAAE,gDAAgD;4BAC1D,KAAK,EAAE,MAAM,CAAC,QAAQ,CAAC,MAAM;yBAC9B,CAAC,CAAC;oBACL,CAAC;gBACH,CAAC;YACH,CAAC,CAAC,CAAC;QACL,CAAC,CAAC,CAAC;QAEH,IAAI,MAAM,CAAC,MAAM,KAAK,CAAC,EAAE,CAAC;YACxB,OAAO,CAAC,GAAG,CAAC,IAAI,CAAC,SAAS,CAAC,MAAM,EAAE,IAAI,EAAE,CAAC,CAAC,EAAE,QAAQ,CAAC,CAAC;YACvD,OAAO;gBACL,OAAO,EAAE,KAAK;gBACd,MAAM;gBACN,IAAI,EAAE,IAAI;aACX,CAAC;QACJ,CAAC;QAED,OAAO,MAAM,CAAC;IAChB,CAAC,CAAC;IACF,OAAO;QACL,QAAQ,EAAE,OAAO;QACjB,IAAI,EAAE,iBAAiB;QACvB,WAAW;QACX,OAAO,EAAE;YACP,YAAY,EAAE,CAAC,IAAI,EAAE,EAAE;gBACrB,KAAK,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC;YACpB,CAAC;SACuC;KAC3C,CAAC;AACJ,CAAC;AAED,MAAM,MAAM;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAMT,CAAC;AACJ,MAAM,UAAU,GAAG;IACjB,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;KAIJ;IACH,MAAM;IACN,KAAK,EAAE,MAAM;IACb,QAAQ,EAAE,MAAM;IAChB,KAAK,EAAE,MAAM;IACb,KAAK;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;KAAgE;CACtE,CAAC"}
@@ -120,6 +120,20 @@ function process(ctx, scenario) {
120
120
  yield agentica.conversate("Create e2e test functions.");
121
121
  if (pointer.value === null)
122
122
  throw new Error("Failed to create test code.");
123
+ const typeReferences = Array.from(new Set(Object.keys(artifacts.document.components.schemas).map((key) => key.split(".")[0])));
124
+ pointer.value.content = pointer.value.content
125
+ .replace(/^[ \t]*import\b[\s\S]*?;[ \t]*$/gm, "")
126
+ .trim();
127
+ pointer.value.content = [
128
+ `import { TestValidator } from "@nestia/e2e";`,
129
+ `import typia, { tags } from "typia";`,
130
+ "",
131
+ `import api from "@ORGANIZATION/PROJECT-api";`,
132
+ ...typeReferences.map((ref) => `import type { ${ref} } from "@ORGANIZATION/PROJECT-api/lib/structures/${ref}";`),
133
+ "",
134
+ pointer.value.content,
135
+ ].join("\n");
136
+ pointer.value.content = pointer.value.content.replaceAll('string & Format<"uuid">', 'string & tags.Format<"uuid">');
123
137
  return pointer.value;
124
138
  });
125
139
  }
@@ -152,7 +166,7 @@ const claude = {
152
166
  properties: {
153
167
  scenario: {
154
168
  title: "Strategic approach for test implementation",
155
- description: "Strategic approach for test implementation.\n\nDefine the high-level strategy and logical flow for testing the given\nscenario. Focus on test methodology, data preparation, and assertion\nstrategy.\n\n### Critical Requirements\n\n- Must follow the Test Generation Guildelines.\n- Must Planning the test code Never occur the typescript compile error.\n\n### Planning Elements:\n\n#### Test Methodology\n\n- Identify test scenario type (CRUD operation, authentication flow,\n validation test)\n- Define test data requirements and preparation strategy\n- Plan positive/negative test cases and edge cases\n- Design assertion logic and validation points\n\n#### Execution Strategy\n\n- Outline step-by-step test execution flow\n- Plan error handling and exception plans\n- Define cleanup and teardown procedures\n- Identify dependencies and prerequisites\n\n### Example Plan:\n\n Test Strategy: Article Creation Validation\n 1. Prepare valid article data with required fields\n 2. Execute POST request to create article\n 3. Validate response structure and data integrity\n 4. Test error plans (missing fields, invalid data)\n 5. Verify database state changes\n 6. Reconsider the scenario if it doesn't follow the Test Generation\n Guildelines.",
169
+ description: "Strategic approach for test implementation.\n\nDefine the high-level strategy and logical flow for testing the given\nscenario. Focus on test methodology, data preparation, and assertion\nstrategy.\n\n### Critical Requirements\n\n- Must follow the Test Generation Guidelines.\n- Must Planning the test code Never occur the TypeScript compile error.\n- NEVER include import statements in planning or implementation.\n\n### Planning Elements:\n\n#### Test Methodology\n\n- Identify test scenario type (CRUD operation, authentication flow,\n validation test)\n- Define test data requirements and preparation strategy\n- Plan positive/negative test cases and edge cases\n- Design assertion logic and validation points\n\n#### Execution Strategy\n\n- Outline step-by-step test execution flow\n- Plan error handling and exception plans\n- Define cleanup and teardown procedures\n- Identify dependencies and prerequisites\n\n### Example Plan:\n\n Test Strategy: Article Creation Validation\n 1. Prepare valid article data with required fields\n 2. Execute POST request to create article\n 3. Validate response structure and data integrity\n 4. Test error plans (missing fields, invalid data)\n 5. Verify database state changes\n 6. Reconsider the scenario if it doesn't follow the Test Generation\n Guidelines.",
156
170
  type: "string"
157
171
  },
158
172
  domain: {
@@ -234,7 +248,7 @@ const collection = {
234
248
  properties: {
235
249
  scenario: {
236
250
  title: "Strategic approach for test implementation",
237
- description: "Strategic approach for test implementation.\n\nDefine the high-level strategy and logical flow for testing the given\nscenario. Focus on test methodology, data preparation, and assertion\nstrategy.\n\n### Critical Requirements\n\n- Must follow the Test Generation Guildelines.\n- Must Planning the test code Never occur the typescript compile error.\n\n### Planning Elements:\n\n#### Test Methodology\n\n- Identify test scenario type (CRUD operation, authentication flow,\n validation test)\n- Define test data requirements and preparation strategy\n- Plan positive/negative test cases and edge cases\n- Design assertion logic and validation points\n\n#### Execution Strategy\n\n- Outline step-by-step test execution flow\n- Plan error handling and exception plans\n- Define cleanup and teardown procedures\n- Identify dependencies and prerequisites\n\n### Example Plan:\n\n Test Strategy: Article Creation Validation\n 1. Prepare valid article data with required fields\n 2. Execute POST request to create article\n 3. Validate response structure and data integrity\n 4. Test error plans (missing fields, invalid data)\n 5. Verify database state changes\n 6. Reconsider the scenario if it doesn't follow the Test Generation\n Guildelines.",
251
+ description: "Strategic approach for test implementation.\n\nDefine the high-level strategy and logical flow for testing the given\nscenario. Focus on test methodology, data preparation, and assertion\nstrategy.\n\n### Critical Requirements\n\n- Must follow the Test Generation Guidelines.\n- Must Planning the test code Never occur the TypeScript compile error.\n- NEVER include import statements in planning or implementation.\n\n### Planning Elements:\n\n#### Test Methodology\n\n- Identify test scenario type (CRUD operation, authentication flow,\n validation test)\n- Define test data requirements and preparation strategy\n- Plan positive/negative test cases and edge cases\n- Design assertion logic and validation points\n\n#### Execution Strategy\n\n- Outline step-by-step test execution flow\n- Plan error handling and exception plans\n- Define cleanup and teardown procedures\n- Identify dependencies and prerequisites\n\n### Example Plan:\n\n Test Strategy: Article Creation Validation\n 1. Prepare valid article data with required fields\n 2. Execute POST request to create article\n 3. Validate response structure and data integrity\n 4. Test error plans (missing fields, invalid data)\n 5. Verify database state changes\n 6. Reconsider the scenario if it doesn't follow the Test Generation\n Guidelines.",
238
252
  type: "string"
239
253
  },
240
254
  domain: {
@@ -319,7 +333,7 @@ const collection = {
319
333
  scenario: {
320
334
  type: "string",
321
335
  title: "Strategic approach for test implementation",
322
- description: "Strategic approach for test implementation.\n\nDefine the high-level strategy and logical flow for testing the given\nscenario. Focus on test methodology, data preparation, and assertion\nstrategy.\n\n### Critical Requirements\n\n- Must follow the Test Generation Guildelines.\n- Must Planning the test code Never occur the typescript compile error.\n\n### Planning Elements:\n\n#### Test Methodology\n\n- Identify test scenario type (CRUD operation, authentication flow,\n validation test)\n- Define test data requirements and preparation strategy\n- Plan positive/negative test cases and edge cases\n- Design assertion logic and validation points\n\n#### Execution Strategy\n\n- Outline step-by-step test execution flow\n- Plan error handling and exception plans\n- Define cleanup and teardown procedures\n- Identify dependencies and prerequisites\n\n### Example Plan:\n\n Test Strategy: Article Creation Validation\n 1. Prepare valid article data with required fields\n 2. Execute POST request to create article\n 3. Validate response structure and data integrity\n 4. Test error plans (missing fields, invalid data)\n 5. Verify database state changes\n 6. Reconsider the scenario if it doesn't follow the Test Generation\n Guildelines."
336
+ description: "Strategic approach for test implementation.\n\nDefine the high-level strategy and logical flow for testing the given\nscenario. Focus on test methodology, data preparation, and assertion\nstrategy.\n\n### Critical Requirements\n\n- Must follow the Test Generation Guidelines.\n- Must Planning the test code Never occur the TypeScript compile error.\n- NEVER include import statements in planning or implementation.\n\n### Planning Elements:\n\n#### Test Methodology\n\n- Identify test scenario type (CRUD operation, authentication flow,\n validation test)\n- Define test data requirements and preparation strategy\n- Plan positive/negative test cases and edge cases\n- Design assertion logic and validation points\n\n#### Execution Strategy\n\n- Outline step-by-step test execution flow\n- Plan error handling and exception plans\n- Define cleanup and teardown procedures\n- Identify dependencies and prerequisites\n\n### Example Plan:\n\n Test Strategy: Article Creation Validation\n 1. Prepare valid article data with required fields\n 2. Execute POST request to create article\n 3. Validate response structure and data integrity\n 4. Test error plans (missing fields, invalid data)\n 5. Verify database state changes\n 6. Reconsider the scenario if it doesn't follow the Test Generation\n Guidelines."
323
337
  },
324
338
  domain: {
325
339
  type: "string",