สร้าง Test Cases ครอบคลุมจาก Function Spec
สร้าง test suite จาก function specification ที่ครอบคลุมทั้ง happy path, edge cases และ adversarial inputs พร้อม rationale ของแต่ละ test และ runnable code ในภาษาและ framework ที่เลือก ช่วย developer เขียน test อย่างเป็นระบบและตรวจจับ bug ที่ซ่อนอยู่ได้อย่างมีประสิทธิภาพ
Given the function specification below, generate a comprehensive test suite covering three mandatory categories:
1. **Happy Path** — valid, typical inputs that the function is designed to handle correctly
2. **Edge Cases** — boundary values, empty strings, null/None/undefined, max/min numeric bounds, empty collections, whitespace-only strings, and type-coercion traps
3. **Adversarial Inputs** — inputs crafted to break or exploit the function: injection strings (SQL, shell, path traversal), excessively long inputs (>10,000 chars), Unicode anomalies (RTL markers, zero-width spaces, emoji), and format-confusion strings (scientific notation, negative zero, NaN, Infinity, etc.)
**Language:** Python
**Test framework:** pytest
---
**Function specification:**
Function: calculate_discount(price: float, discount_percent: float) -> float
- Accepts original price and discount percentage (0 to 100 inclusive)
- Returns the final discounted price, rounded to 2 decimal places
- Raises ValueError if price < 0 or discount_percent is outside range [0, 100]
---
Output in this exact structure:
### Category: Happy Path
| # | Test name | Input(s) | Expected output / behaviour | Rationale |
|---|-----------|----------|----------------------------|-----------|
...
Repeat the same table format for Edge Cases and Adversarial Inputs.
After all three tables, write the complete runnable test code in Python using pytest.
Rules:
- Minimum: 5 happy path, 5 edge case, 5 adversarial test cases
- Test names must follow the pattern: `test_should_<behaviour>_when_<condition>`
- Expected behaviour may be a return value, a raised exception type, or a side-effect description
- Do NOT write or suggest any implementation code — tests only
- Do NOT repeat the function specification verbatim in the output
ถ้าคำตอบยังกว้างไป พิมพ์บอกมันตรงๆ ว่าขอเจาะจงกว่านี้ ไม่ต้องเริ่มพรอมต์ใหม่
ปรับ 3 ช่องให้ตรงกับงานของคุณ
ภาษาโปรแกรมที่ใช้ เช่น Python, TypeScript, Go, Java, Kotlin
testing framework ที่ต้องการใช้ เช่น pytest, Jest, JUnit 5, Go test, RSpec
สเปคของฟังก์ชันที่ต้องการสร้าง test โดยระบุ input, output, และ business rules ให้ครบถ้วน
ผลลัพธ์ที่จะได้
Category: Happy Path
| # | Test name | Input(s) | Expected output / behaviour | Rationale |
|---|---|---|---|---|
| 1 | test_should_return_80_when_20_percent_off_100 | price=100.0, discount_percent=20.0 | 80.0 | กรณีปกติที่ใช้บ่อยที่สุด |
| 2 | test_should_return_same_price_when_zero_discount | price=250.0, discount_percent=0.0 | 250.0 | ไม่มีส่วนลด ราคาต้องไม่เปลี่ยน |
| 3 | test_should_return_zero_when_100_percent_discount | price=500.0, discount_percent=100.0 | 0.0 | ส่วนลด 100% → ได้ฟรี |
| 4 | test_should_round_to_2dp_when_result_is_fractional | price=10.0, discount_percent=33.33 | 6.67 | ตรวจ rounding ให้ครบ 2 ตำแหน่งทศนิยม |
ลองพรอมต์อื่นในแนวเดียวกัน
ดูพรอมต์ทั้งหมด
อธิบาย Legacy Code ให้ทีมใหม่เข้าใจเร็ว พร้อม Flag จุดเสี่ยงและ Tech Debt
ให้ AI วิเคราะห์โค้ดเก่าที่ซับซ้อน สรุปการทำงาน ชี้จุดเสี่ยง และจัดทำ tech debt log พร้อม effort estimate เพื่อให้ทีมใหม่เริ่มต้นได้อย่างปลอดภัยและมีทิศทางชัดเจน

Code Review Checklist 5 มิติ: Correctness, Security, Performance, Style, Test Coverage
พรอมต์สำหรับ developer ที่ต้องการ code review เชิงลึก ครอบคลุม 5 มิติหลัก พร้อมระบบ status icon และ verdict สรุป ช่วยให้ review ได้ครบถ้วนและสม่ำเสมอทุกครั้ง

เขียน Architecture Decision Record (ADR) สำหรับการตัดสินใจทางเทคนิค
สร้าง ADR ที่ครบถ้วนและอ่านง่าย บันทึกบริบท ตัวเลือกที่พิจารณา เหตุผลการตัดสินใจ และ trade-off ที่ยอมรับ ช่วยให้ทีมปัจจุบันและนักพัฒนารุ่นต่อไปเข้าใจว่าทำไมจึงตัดสินใจเช่นนั้น