Interface AutoBeTestScenario

A list of other API endpoints that this scenario logically depends on.

These dependencies represent context or prerequisite conditions, such as authentication, resource creation, or data setup, that are relevant to the test. They should reflect the real policy path needed to reach the target behavior. This list is not a strict execution order — if ordering is important, it must be described explicitly in the purpose.

WARNING: Every endpoint referenced here MUST exist in the provided API operations. Do NOT reference endpoints that are not explicitly available, even if they seem logically necessary based on database schema or business logic.

A detailed natural language description of how this API endpoint should be tested, grounded in the actual business policy and documented API surface. It must name the concrete behavior or precondition being verified, the prerequisite sequence that makes the behavior reachable, the required ordering between steps, the actor or authorization context when relevant, the target action, and the observable assertions. For example, if behavior A is valid only after setup B, the draft must say that B is created or transitioned first and explain why A depends on it. A subsequent agent uses this draft to generate concrete E2E test code, so do not rely on implicit product knowledge or hidden database state.

The API endpoint being tested.

Contains the complete endpoint specification including URL, method, parameters, and expected responses that will be validated by this test scenario.

Descriptive function name derived from the user scenario.

The function name serves as a concise, technical identifier that clearly represents the specific user scenario being described. It should be immediately understandable and directly correspond to the user situation without requiring additional context.

Naming Convention

DO: Use snake_case naming convention.

• Must start with test_api_ prefix (mandatory requirement)
• ALWAYS start with business feature, NOT action verbs
• Business feature comes first, followed by scenario context
• Embed action verbs within the scenario description, not at the beginning

Content Structure

Function names should follow this pattern: test_api_[core_feature]_[specific_scenario]

Where:

• core_feature: The main business feature or entity being tested (customer, seller, cart, push_message, etc.)
• specific_scenario: The specific operation or scenario context (join_verification_not_found, login_success, moderator_assignment_update, discountable_ticket_duplicated, csv_export, etc.)

Business Feature-Based Examples

• test_api_customer_join_verification_not_found - Customer join verification when verification code not found
• test_api_seller_login - Seller login operation
• test_api_cart_discountable_ticket_duplicated - Cart discountable ticket with duplication scenario
• test_api_push_message_csv - Push message functionality with CSV format
• test_api_product_review_update - Product review update operation

Clarity Guidelines

• Prioritize clarity over brevity
• Avoid technical jargon or implementation terms
• Use terminology that reflects user perspective
• Ensure the name alone conveys the user's intent
• Make it understandable to non-technical stakeholders
• Keep consistent with user scenario description

Single Endpoint Alignment

Function names must reflect scenarios that:

• Accomplish user goals through this single endpoint only
• Don't imply dependency on other API operations
• Represent complete user interactions

Grade-gate proof marker, set ONLY when this scenario exercises the authorization grade gate of a grade-restricted target operation (one whose authorization.access.roles is non-empty).

A grade-restricted operation needs two such scenarios — one outcome: "forbidden" (the caller self-assigns an insufficient grade → HTTP 403) and one outcome: "allowed" (a sufficient grade → success). The scenario and operation-write validators read this to enforce that the negative test really proves the 403 and the positive test really pins a qualifying grade. Leave unset for every ordinary scenario.