ทำไมต้องเทสต์ & ประเภทของเทสต์
เทสต์อัตโนมัติคือตาข่ายนิรภัยที่ทำให้คุณกล้าแก้โค้ดโดยไม่กลัวพังโดยไม่รู้ตัว
การเขียนเทสต์เป็นทักษะที่ทำให้โค้ดของคุณเชื่อถือได้และกล้าแก้ไขต่อยอด หัวข้อนี้อธิบายว่าทำไมเทสต์มือ (รันแล้วดูผลเอง) ถึงไม่พอ และประเภทของเทสต์ที่ควรรู้จัก
ปัญหาของการเทสต์ด้วยมือ
เทสต์มือคือรันโปรแกรมแล้วดูผลด้วยตา — ปัญหาคือทำซ้ำทุกครั้งที่แก้โค้ดไม่ไหว พอโปรเจกต์โต การแก้จุดหนึ่งอาจทำอีกจุดพังโดยไม่รู้ (regression) เทสต์อัตโนมัติรันซ้ำได้ทันทีทุกครั้ง
# เทสต์มือ: รันแล้วเพ่งดูเอง (ทำซ้ำทุกครั้งไม่ไหว)
def add(a, b):
return a + b
print(add(2, 3)) # ต้องนั่งดูเองว่าได้ 5 ไหม
# เทสต์อัตโนมัติ: assert บอกทันทีถ้าผิด
assert add(2, 3) == 5
assert add(-1, 1) == 0
print("ผ่านทุกเคส") # ถ้าไม่ขึ้น = มีเคสพังเทสต์ช่วยอะไร
- จับ regression — รู้ทันทีถ้าแก้ของใหม่แล้วของเก่าพัง
- กล้า refactor — มีตาข่ายรองรับ (เชื่อมบท Clean Code)
- เป็นเอกสาร — เทสต์บอกว่าโค้ดควรทำงานยังไง
- ออกแบบดีขึ้น — โค้ดที่เทสต์ง่ายมักออกแบบดี
ประเภทของเทสต์ (Test Pyramid)
เทสต์มีหลายระดับ พีระมิดบอกว่าควรมี unit test เยอะสุด (ฐาน) แล้วลดหลั่นขึ้นไป
| ระดับ | ทดสอบอะไร | ความเร็ว/จำนวน |
|---|---|---|
| Unit | ฟังก์ชัน/หน่วยเล็ก ๆ แยกเดี่ยว | เร็วมาก / เยอะสุด |
| Integration | หลายส่วนทำงานร่วมกัน (เช่น code + DB) | ปานกลาง |
| End-to-End (E2E) | ทั้งระบบเหมือนผู้ใช้จริง | ช้า / น้อยสุด |
หัวใจของเทสต์ไม่ใช่ "พิสูจน์ว่าโค้ดถูก" แต่คือ "ทำให้กล้าเปลี่ยนโค้ด" เพราะถ้าเผลอทำอะไรพัง เทสต์จะร้องทันที คุณจึง refactor และเพิ่มฟีเจอร์ได้อย่างมั่นใจ
สรุปหัวข้อนี้
- เทสต์มือทำซ้ำไม่ไหว — เทสต์อัตโนมัติรันซ้ำได้ทุกครั้ง
- ช่วยจับ regression, กล้า refactor, เป็นเอกสาร
- Test Pyramid: unit (เยอะสุด) > integration > e2e (น้อยสุด)
- เป้าหมายหลักคือ "กล้าเปลี่ยนโค้ดอย่างมั่นใจ"
1) เขียนฟังก์ชัน is_even(n) แล้วเขียน assert 3 เคสตรวจ 2) จงใจแก้ฟังก์ชันให้ผิดแล้วดูว่า assert จับได้ 3) ยกตัวอย่างงานที่ควรเป็น unit test กับงานที่ควรเป็น integration test 4) อธิบายว่าทำไมเทสต์ทำให้กล้า refactor