TDD: Red, Green, Refactor

1 · วงจร Red → Green → Refactor

ปกติเราเขียนโค้ดก่อน แล้วค่อยลองดูว่าใช้ได้ไหม TDD สลับสองอย่างนี้: เขียน "ตัวตรวจ" ก่อน แล้วค่อยเขียนของที่จะให้มันตรวจ ตัวตรวจในที่นี้คือเทส — โค้ดสั้น ๆ ที่เรียกฟังก์ชันของเรา แล้วเช็คว่าผลตรงกับที่ควรจะเป็นไหม
(production code ในตารางข้างล่าง = “โค้ดจริงที่จะได้ใช้งาน” ตรงข้ามกับโค้ดเทส)

       ┌──────────────────────────────────────────┐
       │                                          ▼
   [Red]  ─────────▶  [Green]  ─────────▶  [Refactor]
  เขียนเทสให้พัง      แก้ให้ผ่าน           ทำให้สวย
   (ไฟแดง)          (ไฟเขียว)        (โดยเทสยังเขียว)

2 · Red มีสองแบบ — และมีแบบเดียวที่ใช่

ผมทดลองให้ดูแล้วด้วย Division(a, b float64) — เริ่มจากเขียนเทสก่อน โดยที่ยังไม่มีฟังก์ชันเลย

// division_test.go — เขียนอันนี้ก่อน
func TestDivision(t *testing.T) {
    got, err := Division(10, 2)
    if err != nil {
        t.Fatalf("ไม่ควรมี error: %v", err)
    }
    if got != 5 {
        t.Errorf("Division(10,2) = %v; want 5", got)
    }
}

$ go test ./...
# tdd [tdd.test]
./division_test.go:6:14: undefined: Division
FAIL	tdd [build failed]

// เขียนโครงเปล่า ๆ ก่อน
func Division(a, b float64) (float64, error) {
    return 0, nil
}
$ go test ./...
--- FAIL: TestDivision (0.00s)
    division_test.go:11: Division(10,2) = 0; want 5
FAIL

3 · Green — เขียนน้อยที่สุด

func Division(a, b float64) (float64, error) {
    return a / b, nil          // พอแล้วสำหรับเทสที่มีตอนนี้
}

$ go test ./...
ok  	tdd	0.464s      ← 🟢

รอบที่ 2 — Red อีกครั้ง

รอบนี้ยังไม่ต้องแปลงเป็นตาราง (เก็บไว้ทำตอน Refactor) — แค่เพิ่มเทสอีกฟังก์ชันสำหรับพฤติกรรมใหม่ และสังเกตว่าเทสนี้ยังไม่พูดถึง ErrDivideByZero เลย เพราะตัวแปรนั้นยังไม่ถูกประกาศ — ถ้าอ้างตอนนี้จะได้ build failed ซึ่งหัวข้อ 2 เพิ่งบอกว่ายังไม่ใช่ Red

// division_test.go — เพิ่มต่อท้าย
func TestDivision_ByZero(t *testing.T) {
    _, err := Division(10, 0)
    if err == nil {
        t.Errorf("Division(10,0) err = <nil>; want divide by zero")
    }
}

$ go test ./...
--- FAIL: TestDivision_ByZero (0.00s)
    division_test.go:18: Division(10,0) err = <nil>; want divide by zero
FAIL
FAIL	tdd	0.433s
FAIL      ← 🔴

Green อีกครั้ง

var ErrDivideByZero = errors.New("divide by zero")

func Division(a, b float64) (float64, error) {
    if b == 0 {
        return 0, ErrDivideByZero
    }
    return a / b, nil
}

$ go test ./...
ok  	tdd	0.464s      ← 🟢 ทั้งสองเคสผ่าน

4 · Refactor — ขั้นที่คนข้ามบ่อยที่สุด

ตอนนี้เทสเขียวแล้ว = คุณมีตาข่ายนิรภัย แก้โครงสร้างโค้ดได้อย่างมั่นใจ เพราะถ้าทำพัง เทสจะบอกทันที

• ตั้งชื่อตัวแปรใหม่ให้สื่อความหมาย
• แยกฟังก์ชันที่ยาวเกินไป
• ยุบ if ซ้อนเป็น guard clause (บทเรียน 04)
• เปลี่ยน float64 เป็น custom type ให้สื่อความหมาย (บทเรียน 09)

5 · TDD ได้อะไรมากกว่า "มีเทส"

6 · Test with AI workflow

ทุกวันนี้ AI generate โค้ดได้ทั้งไฟล์ในไม่กี่วินาที แต่โค้ดที่ได้อาจไม่ตรงกับสิ่งที่ธุรกิจต้องการ — AI เดาจากบริบทที่คุณให้ ถ้าบริบทกำกวม มันก็เดาไปทางที่ดูสมเหตุสมผลที่สุด ซึ่งอาจไม่ใช่สิ่งที่คุณหมายถึง

ปัญหา: AI เก่งเรื่อง "เขียนโค้ด" แต่ไม่รู้ "ธุรกิจต้องการอะไร"

  คุณ ──"เขียนฟังก์ชันคำนวณส่วนลด"──▶ AI ──▶ โค้ดที่ดูดี
                                              │
                                              ▼
                                   แล้วยังไงถึงจะรู้ว่าถูก?

ทางแก้: ให้เทสเป็นตัวกำหนดข้อตกลง แล้วปล่อย AI เขียน implementation

  คุณ ──▶ เขียนเทส (สเปกที่รันได้) ──▶ AI เขียนโค้ด ──▶ go test
                     ▲                                          │
                     └──────────── แดง = ยังไม่ตรง ◀────────────┘

ทำไมเทสเหมาะกับงานนี้เป็นพิเศษ

• เทสคือสเปกที่รันได้ — ต่างจากคำอธิบายภาษาคน ตรงที่ไม่มีทางตีความผิด และตรวจสอบอัตโนมัติได้
• AI ตรวจงานตัวเองได้ — บอกให้รัน go test แล้วแก้จนเขียว โดยไม่ต้องรอคุณ review ทุกรอบ
• คุณยังคุมความหมาย — คุณเป็นคนตัดสินใจว่า "ส่วนลด 100% แล้วราคาควรเป็น 0 หรือควร error" ซึ่ง AI เดาเองไม่ได้

รูปแบบที่ใช้ได้จริง

1. คุณ:   เขียน table-driven test ที่ระบุพฤติกรรมทุกเคส (รวมเคสขอบ)
2. คุณ:   รันให้เห็นแดง — พิสูจน์ว่าเทสจับได้จริง
3. AI:    เขียน implementation ให้ผ่านเทสทั้งหมด
4. AI:    รัน go test เอง แก้เอง จนเขียว
5. คุณ:   อ่านโค้ดที่ได้ — ตรวจว่ามันไม่ได้ "โกง" เทส
6. คุณ:   เพิ่มเคสที่นึกออกเพิ่ม → กลับไปข้อ 2

// เทสที่คุณเขียน — มีเคสเดียว
func TestCalculateDiscount(t *testing.T) {
    got, err := CalculateDiscount(100, 10)
    require.NoError(t, err)
    assert.Equal(t, 90, got)
}

// implementation ที่ได้กลับมา
func CalculateDiscount(price, percent int) (int, error) {
    if price == 100 && percent == 10 {
        return 90, nil
    }
    return 0, nil
}

7 · ทดสอบความจำ

8 · ลงมือทำ

อ่านต่อจากต้นทาง

แหล่งหลักที่แนะนำ: Learn Go with Tests ของ Chris James — สอน Go ทั้งภาษาผ่าน TDD ตั้งแต่ hello world ถึง concurrency ทุกบทเป็นวงจร red-green-refactor จริง ๆ ฟรี อ่านออนไลน์ได้ และเป็นแหล่งที่ชุมชน Go แนะนำกันมากที่สุดสำหรับเรื่องนี้
ถ้าจะอ่านต่อจากบทนี้แค่ที่เดียว ให้อ่านที่นั่น

อ้างอิง

• Learn Go with Tests — เรียน Go ทั้งภาษาผ่าน TDD (ฟรี)
• Add a test — Go tutorial — ทางการ เริ่มต้นสั้น ๆ
• Go Wiki — Table Driven Tests
• pkg.go.dev — testing
• Go Code Review Comments — Useful Test Failures