Mission 2 API Test Scenario Creation Practice Guide
📥 Practice Input
- •
day4_api_contract.md(DB physical schema definition)
💾 Practice output (Output)
- •
edge-case-analysis.md(Exception scenario report)
1. Story and practice background
On the first night of a startup's successful launch of its MVP product, an unexpected server alarm sounds. Two users pressed the payment button at the same time during the same reservation time slot, and both payments were successful, but only the last payer was overwritten in the database, and the reservation data of the first payer was lost. (Concurrency control exception situation)
In actual services, numerous edge cases occur, such as abnormal user input, incorrect format transmission, missing required keys, and unauthorized unauthorized requests. If you do not carefully prepare and build a corresponding API test scenario in advance, the real-time monitoring window will be filled with red alarms after release.
In this mission, we automatically create an API test scenario that verifies not only the normal flow but also exceptional conditions and boundary values based on the completed API specification contract, thereby improving the ability to defend stable, error-free services.
2. Learning objectives
- Logical design flaws can be detected in defined table schemas and foreign key reference structures.
- Edge case scenarios such as concurrent writing, TC-API-RES-002 / collapse due to missing required fields, and transaction rollback failure can be derived.
- You can prepare countermeasures such as soft delete (logical deletion) to defend against hard delete withdrawal.
🛠️Practical guide to follow along
- Create file for practice: Click the download button below
day4_api_contract.mdDownload the fileautomation/Save it within the folder. - Codex Verification Delegation: Build by sending the **Codex request prompt** below to the Codex Client prompt input window.
- Confirmation of response design: In the derived report, we review whether specific DB improvement measures, such as duplicate reservation prevention measures (distributed lock/unique constraints) and soft delete logical identifier design, have been established.
Download practice materials
Codex request prompt
Mission 02 Prompt
Based on the currently defined reservation and payment API specifications, please create an API test scenario and verification checklist that includes both the normal registration flow (Happy Path) and exception cases such as missing required parameters, date format errors, limit exceeded, and permission expiration.
4. Example results
Codex white-boxes the schema logic and derives the following fatal exception scenarios:
| Scenario ID/Item | Prerequisites and Test Procedures (Edge Case) | system impact | Expected behavior |
|---|---|---|---|
| TC-API-RES-001 / Reservation creation OK | A phenomenon in which two users make a reservation and payment at the same time during the same consultation time and both are judged successful, resulting in duplicate mapping. | fatal | Create complex UNIQUE constraints on DB reserved tables or apply Redis distributed locks |
| TC-API-RES-002 / Required field missing | A phenomenon in which daily sales settlement statistics queries are broken due to the foreign key relationship being broken due to hard deleting of user records with payment history. | fatal | Changed Soft Delete (logical delete) table design to record is_deleted column and deletion time |
| TC-API-RES-003 / Date format error | External PG payment approval was successful, but it was rolled back due to a network failure at the DB insert stage and the payment record was disassembled. | Normal | Bundle payment transactions into distributed transactions (Saga Pattern) and run a batch verification script for unconfirmed payments |