คุณเพิ่มเทสต์ให้กับ legacy code อย่างไร?

Question

Accepted Answer

**Legacy code** (โค้ดที่มักไม่มีเทสต์และเปลี่ยนแปลงยาก) เป็นเรื่องท้าทายในการทดสอบ — มันอาจมี dependency ที่พันกันยุ่งเหยิงและไม่มีเทสต์ การเพิ่มเทสต์อย่างปลอดภัยเกี่ยวข้องกับเทคนิคอย่าง **characterization test**, **seam** สำหรับการตัด dependency และการปรับปรุงทีละขั้น ซึ่งช่วยให้เปลี่ยนแปลงได้ปลอดภัยขึ้น

## ความท้าทายของ legacy code

```text
Legacy code is often: untested, tightly coupled, hard to understand, risky to change:
  → no tests → changing it is dangerous (you can't tell if you broke something)
  → hard to test → dependencies are tangled (can't isolate units); not designed for testing
→ a chicken-and-egg problem: to change safely you need tests, but it's hard to test.
```

## Characterization test (ตรึงพฤติกรรมปัจจุบัน)

```text
CHARACTERIZATION (golden master) tests → capture the code's CURRENT behavior as-is
  (even if you don't fully understand it / it has bugs):
  → write tests asserting what it ACTUALLY does now → a SAFETY NET
  → then you can refactor/change with confidence that behavior is preserved
→ Don't assert what it SHOULD do — assert what it DOES, to protect against regressions.
```

## การตัด dependency (seams)

```text
To isolate hard-to-test code, find/create SEAMS (places to substitute dependencies):
  → extract dependencies behind interfaces; inject them; use the smallest safe refactors
    to make code testable (Michael Feathers' techniques)
  → carefully break dependencies so you can get the code under test, then test, then refactor
```

## แนวทางแบบทีละขั้น

```text
✓ Add tests AROUND code BEFORE changing it (a safety net for the change)
✓ Focus on areas you're CHANGING / high-risk / high-value (not the whole codebase at once)
✓ Improve incrementally — leave code a bit better each time (the "boy scout rule")
✓ Use characterization tests to capture behavior, then refactor toward testability
```

## ทำไมจึงสำคัญ

การเข้าใจวิธีเพิ่มเทสต์ให้กับ legacy code เป็นความรู้ระดับ senior ที่มีคุณค่าเพราะ **งานในโลกจริงส่วนใหญ่เกี่ยวข้องกับโค้ดที่มีอยู่แล้วซึ่งมักไม่มีเทสต์** และการปรับปรุงมันอย่างปลอดภัยเป็นความท้าทายที่พบบ่อยและสำคัญ จึงเกี่ยวข้องในทางปฏิบัติ

Legacy code (ไม่มีเทสต์ coupled แน่น เปลี่ยนแปลงยาก) นำเสนอ **ปัญหาไก่กับไข่** ที่แท้จริง: เพื่อเปลี่ยนแปลงมันอย่างปลอดภัยคุณต้องการเทสต์ แต่มันทดสอบยาก (dependency พันกันยุ่งเหยิง ไม่ได้ออกแบบมาเพื่อทดสอบ) — และการเปลี่ยนโค้ดที่ไม่มีเทสต์เป็นอันตรายเพราะคุณบอกไม่ได้ว่าคุณทำอะไรพังไปหรือเปล่า

การเข้าใจเทคนิคในการจัดการสิ่งนี้เป็นความรู้ที่มีคุณค่าในทางปฏิบัติ **Characterization test** (การจับพฤติกรรม *ปัจจุบัน* ของโค้ดตามที่เป็น ยืนยันสิ่งที่มันทำจริงแทนที่จะเป็นสิ่งที่ควรทำ — แม้จะไม่เข้าใจเต็มที่) ให้ **safety net** ที่ช่วยให้คุณ refactor และเปลี่ยนแปลงด้วยความมั่นใจว่าพฤติกรรมที่มีอยู่ยังคงอยู่ — เทคนิคสำคัญสำหรับการทำงานกับโค้ดที่คุณไม่เข้าใจเต็มที่

การเข้าใจ **การตัด dependency ผ่าน seam** (การหาหรือสร้างจุดที่จะแทนที่ dependency โดยใช้ refactor ที่ปลอดภัยน้อยที่สุดเพื่อทำให้โค้ดที่พันกันยุ่งเหยิงทดสอบได้ — เทคนิคจากงานของ Michael Feathers เกี่ยวกับ legacy code) จำเป็นต่อการนำโค้ดที่ทดสอบยากมาอยู่ภายใต้การทดสอบ

การเข้าใจ **แนวทางแบบทีละขั้น** — การเพิ่มเทสต์รอบ ๆ โค้ดก่อนเปลี่ยนมัน (safety net สำหรับการเปลี่ยนแปลง) การมุ่งเน้นพื้นที่ที่กำลังเปลี่ยนหรือความเสี่ยงสูง/คุณค่าสูง (ไม่ใช่ทั้ง codebase พร้อมกัน) และการปรับปรุงทีละขั้น (boy scout rule) — สะท้อนวิธีที่เป็นรูปธรรมและสมจริงในการปรับปรุง legacy system ตามกาลเวลา

เนื่องจากการพัฒนาในโลกจริงส่วนใหญ่เกี่ยวข้องกับ legacy code ที่มีอยู่แล้วซึ่งมักไม่มีเทสต์และต้องเปลี่ยนแปลงอย่างปลอดภัย (สถานการณ์ที่พบบ่อยและท้าทาย) และเนื่องจากการเข้าใจเทคนิค (characterization test เพื่อ safety net, seam สำหรับการตัด dependency, การปรับปรุงทีละขั้น) ช่วยให้ทำสิ่งนี้ได้ การเข้าใจวิธีเพิ่มเทสต์ให้กับ legacy code จึงเป็นความรู้ระดับ senior ที่มีคุณค่า — เกี่ยวข้องในทางปฏิบัติต่อความเป็นจริงทั่วไปของการทำงานกับโค้ดที่มีอยู่แล้วซึ่งไม่มีเทสต์ สะท้อนประสบการณ์และเทคนิคที่จำเป็นต่อการปรับปรุง legacy system อย่างปลอดภัย สมรรถนะสำคัญสำหรับวิศวกร senior ที่มักต้องทำให้โค้ดที่ไม่มีเทสต์เปลี่ยนแปลงได้อย่างปลอดภัยขึ้น