สร้าง Test Cases ครอบคลุมจาก Function Spec
สร้าง test suite จาก function specification ที่ครอบคลุมทั้ง happy path, edge cases และ adversarial inputs พร้อม rationale ของแต่ละ test และ runnable code ในภาษาและ framework ที่เลือก ช่วย developer เขียน test อย่างเป็นระบบและตรวจจับ bug ที่ซ่อนอยู่ได้อย่างมีประสิทธิภาพ
คัดลอกพรอมต์ฉบับมีตัวแปร {{...}} ไปแก้ไขในเครื่องมือของคุณเอง
ตัวอย่างผลลัพธ์ที่จะได้
ก่อนเริ่มลงมือปรับพรอมต์ ดูตัวอย่างผลลัพธ์ที่คุณจะได้จริงเพื่อให้แน่ใจว่าพรอมต์นี้ตรงกับงานที่ต้องการ
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 ตำแหน่งทศนิยม |
| 5 | test_should_handle_large_price_when_standard_discount | price=999999.99, discount_percent=15.0 | 849999.99 | ราคาสูงมาก ต้องไม่เกิด float precision error |
Category: Edge Cases
| # | Test name | Input(s) | Expected output / behaviour | Rationale |
|---|
ปรับให้เข้ากับงานของคุณ
แก้ค่าตัวแปรด้านล่าง พรอมต์ฉบับสมบูรณ์จะอัปเดตอัตโนมัติ พร้อมคัดลอกไปวางใน Claude หรือ ChatGPT ได้ทันที
ภาษาโปรแกรมที่ใช้ เช่น Python, TypeScript, Go, Java, Kotlin
testing framework ที่ต้องการใช้ เช่น pytest, Jest, JUnit 5, Go test, RSpec
สเปคของฟังก์ชันที่ต้องการสร้าง test โดยระบุ input, output, และ business rules ให้ครบถ้วน
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
เข้าใจเทคนิคที่ซ่อนอยู่
คลิกที่ส่วนไฮไลต์ในพรอมต์เพื่อกระโดดไปดูคำอธิบายเทคนิคแต่ละจุด ใช้ความเข้าใจนี้เพื่อปรับพรอมต์อื่นของคุณเองในภายหลัง
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:** {{language}}
**Test framework:** {{test_framework}}
---
**Function specification:**
{{function_spec}}
---
Output in this exact structure:
### Category: Happy Path
| # | Test name | Input(s) | Expected output / behaviour | Rationale |3
|---|-----------|----------|----------------------------|-----------|
...
Repeat the same table format for Edge Cases and Adversarial Inputs.
After all three tables, write the complete runnable test code in {{language}} using {{test_framework}}.
Rules:
- Minimum: 5 happy path, 5 edge case, 5 adversarial test cases4
- Test names must follow the pattern: `test_should_<behaviour>_when_<condition>`5
- 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 only6
- Do NOT repeat the function specification verbatim in the output
แตะส่วนที่ไฮไลต์เพื่อดูคำอธิบายเทคนิคแต่ละจุด · {{ }} คือตัวแปรที่ปรับได้
"You are a senior software test engineer with deep expertise in test-driven development, security testing, and edge-case analysis."
การกำหนด role เป็น senior test engineer ที่มี expertise ด้าน security และ edge-case ทำให้โมเดลเลือกใช้กรอบความคิดเชิงคุณภาพและความปลอดภัย แทนที่จะเขียน test แบบผิวเผิน
"1. **Happy Path** — valid, typical inputs... 2. **Edge Cases** — boundary values... 3. **Adversarial Inputs** — inputs crafted to break or exploit the function"
การแบ่ง 3 หมวดพร้อมคำนิยามชัดเจนบังคับให้โมเดลคิดครอบคลุมทุกมิติของการทดสอบ ป้องกันการข้ามหมวดที่ยากกว่า เช่น adversarial inputs
"Output in this exact structure: ### Category: Happy Path | # | Test name | Input(s) | Expected output / behaviour | Rationale |"
การกำหนด output เป็นตารางที่มีคอลัมน์ครบถ้วนบังคับให้โมเดลระบุ rationale ของทุก test case ซึ่งทำให้ผลลัพธ์ตรวจสอบและนำไปใช้งานได้ทันที
"Minimum: 5 happy path, 5 edge case, 5 adversarial test cases"
การกำหนดจำนวน minimum ในแต่ละหมวดป้องกันการตอบสั้นเกินไป และทำให้แน่ใจว่าโมเดลจะพิจารณา scenario ที่หลากหลายเพียงพอ
"Test names must follow the pattern: `test_should_<behaviour>_when_<condition>`"
การบังคับ naming pattern ทำให้ test ทุกตัวอธิบายตัวเองได้โดยไม่ต้องอ่าน implementation ซึ่งเป็น best practice ของ clean test code
"Do NOT write or suggest any implementation code — tests only"
การห้ามเขียน implementation ป้องกันโมเดลจากการเบี่ยงเบนออกนอก scope ซึ่งมักเกิดขึ้นเมื่อ spec ยังไม่ครบถ้วน โมเดลมักจะ "ช่วย" เขียน code ให้โดยไม่ได้รับอนุญาต
เห็นความต่างระหว่างพรอมต์ทั่วไปกับพรอมต์ที่ใช้เทคนิค
คนส่วนใหญ่เริ่มต้นด้วยคำสั่งสั้น ๆ แบบพรอมต์ที่ใช้กันทั่วไป แต่ผลลัพธ์มักไม่ตรงใจและต้องถามซ้ำหลายรอบ พรอมต์แบบที่ใช้เทคนิคข้างต้นช่วยแก้ปัญหานี้
เขียน test cases สำหรับฟังก์ชัน calculate_discount ให้หน่อย
กำหนด role เป็น senior test engineer, แบ่ง 3 หมวดชัดเจนพร้อมคำนิยาม (happy/edge/adversarial), บังคับ output เป็นตารางที่มี rationale + runnable code, กำหนด minimum จำนวน test case ต่อหมวด, บังคับ naming pattern, และห้ามเขียน implementation
