สร้าง 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 |
|---|---|---|---|---|
| 1 | test_should_return_zero_when_price_is_zero | price=0.0, discount_percent=50.0 | 0.0 | ราคา 0 ต้องคืน 0 เสมอ ไม่ว่า discount จะเป็นเท่าใด |
| 2 | test_should_return_same_when_discount_is_boundary_0 | price=1000.0, discount_percent=0.0 | 1000.0 | boundary ล่างของ discount ต้องไม่ raise |
| 3 | test_should_return_zero_when_discount_is_boundary_100 | price=1000.0, discount_percent=100.0 | 0.0 | boundary บนของ discount ต้องไม่ raise |
| 4 | test_should_round_up_when_third_decimal_is_5 | price=0.015, discount_percent=0.0 | 0.02 | banker's rounding vs standard rounding อาจให้ผลต่างกัน |
| 5 | test_should_handle_minimum_currency_unit | price=0.01, discount_percent=50.0 | 0.01 | หน่วยเงินที่เล็กที่สุด ต้องไม่กลายเป็น 0.0 |
Category: Adversarial Inputs
| # | Test name | Input(s) | Expected output / behaviour | Rationale |
|---|---|---|---|---|
| 1 | test_should_raise_when_price_is_negative | price=-1.0, discount_percent=10.0 | raises ValueError | ราคาติดลบไม่มีความหมายทางธุรกิจ |
| 2 | test_should_raise_when_discount_exceeds_100 | price=100.0, discount_percent=101.0 | raises ValueError | ส่วนลดเกิน 100% ควร reject ทันที |
| 3 | test_should_raise_when_discount_is_negative | price=100.0, discount_percent=-0.001 | raises ValueError | negative discount = ขึ้นราคา ต้องไม่อนุญาต |
| 4 | test_should_raise_when_price_is_nan | price=float('nan'), discount_percent=10.0 | raises ValueError | NaN propagates silently ทำให้ผลลัพธ์ไม่น่าเชื่อถือ |
| 5 | test_should_raise_when_price_is_infinity | price=float('inf'), discount_percent=10.0 | raises ValueError | inf ทำให้คำนวณผิดพลาดโดยไม่มี error ชัดเจน |
import pytest
import math
from pricing import calculate_discount
# ── Happy Path ────────────────────────────────────────────────────────────────
class TestHappyPath:
def test_should_return_80_when_20_percent_off_100(self):
assert calculate_discount(100.0, 20.0) == 80.0
def test_should_return_same_price_when_zero_discount(self):
assert calculate_discount(250.0, 0.0) == 250.0
def test_should_return_zero_when_100_percent_discount(self):
assert calculate_discount(500.0, 100.0) == 0.0
def test_should_round_to_2dp_when_result_is_fractional(self):
assert calculate_discount(10.0, 33.33) == 6.67
def test_should_handle_large_price_when_standard_discount(self):
assert calculate_discount(999999.99, 15.0) == 849999.99
# ── Edge Cases ────────────────────────────────────────────────────────────────
class TestEdgeCases:
def test_should_return_zero_when_price_is_zero(self):
assert calculate_discount(0.0, 50.0) == 0.0
def test_should_return_same_when_discount_is_boundary_0(self):
assert calculate_discount(1000.0, 0.0) == 1000.0
def test_should_return_zero_when_discount_is_boundary_100(self):
assert calculate_discount(1000.0, 100.0) == 0.0
def test_should_round_up_when_third_decimal_is_5(self):
assert calculate_discount(0.015, 0.0) == 0.02
def test_should_handle_minimum_currency_unit(self):
assert calculate_discount(0.01, 50.0) == 0.01
# ── Adversarial Inputs ────────────────────────────────────────────────────────
class TestAdversarialInputs:
def test_should_raise_when_price_is_negative(self):
with pytest.raises(ValueError):
calculate_discount(-1.0, 10.0)
def test_should_raise_when_discount_exceeds_100(self):
with pytest.raises(ValueError):
calculate_discount(100.0, 101.0)
def test_should_raise_when_discount_is_negative(self):
with pytest.raises(ValueError):
calculate_discount(100.0, -0.001)
def test_should_raise_when_price_is_nan(self):
with pytest.raises(ValueError):
calculate_discount(float('nan'), 10.0)
def test_should_raise_when_price_is_infinity(self):
with pytest.raises(ValueError):
calculate_discount(float('inf'), 10.0)
ขั้นตอนที่ 1
ปรับให้เข้ากับงานของคุณ
แก้ค่าตัวแปรด้านล่าง พรอมต์ฉบับสมบูรณ์จะอัพเดทอัตโนมัติพร้อมก๊อปไปวางใน Claude หรือ ChatGPT ได้ทันที
You are a senior software test engineer with deep expertise in test-driven development, security testing, and edge-case analysis. 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
ขั้นตอนที่ 2
เข้าใจเทคนิคที่ซ่อนอยู่
คลิกที่ส่วนไฮไลต์ในพรอมต์เพื่อกระโดดไปดูคำอธิบายเทคนิคแต่ละจุด ใช้ความเข้าใจนี้เพื่อปรับพรอมต์อื่นของคุณเองในภายหลัง
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}} --- |---|-----------|----------|----------------------------|-----------| ... 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: - - - Expected behaviour may be a return value, a raised exception type, or a side-effect description - - Do NOT repeat the function specification verbatim in the output
- 1Role assignment
“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 แบบผิวเผิน
- 2Step-by-step instruction
“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
- 3Output format constraint
“Output in this exact structure: ### Category: Happy Path | # | Test name | Input(s) | Expected output / behaviour | Rationale |”
การกำหนด output เป็นตารางที่มีคอลัมน์ครบถ้วนบังคับให้โมเดลระบุ rationale ของทุก test case ซึ่งทำให้ผลลัพธ์ตรวจสอบและนำไปใช้งานได้ทันที
- 4Quantified constraint
“Minimum: 5 happy path, 5 edge case, 5 adversarial test cases”
การกำหนดจำนวน minimum ในแต่ละหมวดป้องกันการตอบสั้นเกินไป และทำให้แน่ใจว่าโมเดลจะพิจารณา scenario ที่หลากหลายเพียงพอ
- 5Naming convention constraint
“Test names must follow the pattern: `test_should_<behaviour>_when_<condition>`”
การบังคับ naming pattern ทำให้ test ทุกตัวอธิบายตัวเองได้โดยไม่ต้องอ่าน implementation ซึ่งเป็น best practice ของ clean test code
- 6Negative constraint
“Do NOT write or suggest any implementation code — tests only”
การห้ามเขียน implementation ป้องกันโมเดลจากการเบี่ยงเบนออกนอก scope ซึ่งมักเกิดขึ้นเมื่อ spec ยังไม่ครบถ้วน โมเดลมักจะ "ช่วย" เขียน code ให้โดยไม่ได้รับอนุญาต
ขั้นตอนที่ 3
เห็นความต่าง พรอมต์ทั่วไป vs พรอมต์ที่ใช้เทคนิค
คนส่วนใหญ่เริ่มต้นด้วยคำสั่งสั้นๆ แบบฝั่งซ้าย แต่ผลลัพธ์มักไม่ตรงใจและต้องถามซ้ำหลายรอบ พรอมต์แบบฝั่งขวาแก้ปัญหานี้ด้วยเทคนิคที่อธิบายข้างต้น
พรอมต์แบบที่ใช้กันทั่วไป
เขียน test cases สำหรับฟังก์ชัน calculate_discount ให้หน่อย
พรอมต์แบบที่ใช้เทคนิคข้างบน
กำหนด role เป็น senior test engineer, แบ่ง 3 หมวดชัดเจนพร้อมคำนิยาม (happy/edge/adversarial), บังคับ output เป็นตารางที่มี rationale + runnable code, กำหนด minimum จำนวน test case ต่อหมวด, บังคับ naming pattern, และห้ามเขียน implementation
ทำไมแบบที่ใช้เทคนิคถึงดีกว่า
คำสั่งแบบสั้นไม่บอกว่า "ครอบคลุม" หมายถึงอะไร โมเดลจึงมักเขียนแค่ happy path 3-5 case แล้วหยุด โดยไม่แตะ edge cases หรือ adversarial inputs เลย เวอร์ชันที่ดีกว่าบังคับให้โมเดลคิดในกรอบ 3 หมวดพร้อมระบุจำนวน minimum และ naming convention ซึ่งทำให้ได้ test suite ที่พร้อม merge เข้า codebase จริงได้ทันที
พรอมต์ที่เกี่ยวข้อง
ลองพรอมต์อื่นในแนวเดียวกัน
งานโค้ด
อธิบาย 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 ที่ยอมรับ ช่วยให้ทีมปัจจุบันและนักพัฒนารุ่นต่อไปเข้าใจว่าทำไมจึงตัดสินใจเช่นนั้น
งานโค้ด
อธิบาย Error Message ให้เข้าใจง่ายพร้อมแก้ทีละขั้นและป้องกันซ้ำ
พรอมต์สำหรับนักพัฒนาที่ต้องการอ่าน error message ที่ซับซ้อนให้เข้าใจง่าย รับคำแนะนำแก้ไขทีละขั้นตอน และเรียนรู้วิธีป้องกันไม่ให้ปัญหาเดิมเกิดซ้ำในอนาคต