
จากที่ได้แบ่งปันเรื่องการเขียน test เพื่อให้ได้ผลที่ดี
ว่าต้องทำอย่างไรบ้าง จึงทำการสรุปำว้นิดหน่อย
สิ่งหนึ่งที่เน้นย้ำคือ เราทดสอบเพื่อสร้างความมั่นใจของเราที่มีต่อระบบ
ไม่ได้ทำเพื่อใคร แต่เพื่อตัวเราเอง
เดินไปข้างหน้า โดยไม่ห่วงข้างหลัง
แล้วผลอื่น ๆ ที่ตามมา มันเป็นเพียงผลพลอยได้
ดังนั้น สำหรับใครก็ตามที่เขียน code ขึ้นมาได้
ก็น่าจะต้องสร้างความมั่นใจให้กับตัวเองด้วย
หนึ่งในวิธีการคือ การเขียน test นั่นเอง
อีกหนึ่งคำถามที่ต้องตอบให้ได้คือ
ถ้าตอนนี้เรากำลังเพิ่ม feature ใหม่เข้าไป
เรามั่นใจไหมว่า feature ก่อนหน้านี้ยังทำงานได้เช่นเดิม
แนวทางที่ได้แบ่งปันไว้มีดังนี้
- เริ่มจาก code ที่ testable หรือ สามารถทดสอบได้ง่าย นั่นคือ คิดก่อนว่าจะทดสอบอย่างไร ก่อนจะทดสอบหรือสร้าง
- เรื่องของ test strategy สำคัญมาก ๆ ต้องตอบให้ได้ หรือ ตกลงกันก่อน ว่าจะทดสอบแบบไหน อย่างไร มีขอบเขตอย่างไร ก็ลงมือ เช่น unit test, integration test, component test, contract test และ end-to-end test เป็นต้น
- ใน test case จะมีโครงสร้างมาตรฐาน โดยมักจะแนะนำ AAA (Arrange-Act-Assert)
- แต่ละ test case ควรที่จะเป็นอิสระแก่กัน ไม่ใช่ต้อง test แบบเรียงลำดับ เพื่อลดปัญหาของการทดสอบ ทั้ง flaky test, ไม่สามารถทำ parallel testing ได้ รวมทั้งเรื่องเวลาในการทดสอบที่อาจจะนานจนเกินไป ต้องตกลงกันให้ชัดเจน ว่าแนวทางไหนที่ส่งผลดีต่อการพัฒนาและส่งมอบระบบ
- แต่ละ test case ควรจัดการ external dependency ให้ดี ๆ ทั้ง datetime, random value, database และ external system เป็นต้น เพราะว่า ถ้าจัดการไม่ดี การทดสอบซ้ำเป็นไปได้ยากมาก ๆ ไม่ใช่อะไรก็จะ mock กันอย่างเดียว !!
- ในการทดสอบควรต้องเข้าใจเรื่องของ data test ด้วย ควรให้ครบและครอบคลุม ทั้ง normal case, edge case และ invalid case อาจจะรวมไปถึง non-functional case ด้วย
- ชื่อของ test case ควรอ่านเข้าใจได้ง่าย มีความหมายชัดเจน ว่ากำหนดทดสอบเรื่องอะไร ด้วยเงื่อนไขอะไร ผลที่คาดหวังคืออะไร เพื่อให้ง่ายต่อการดูแลรักษาต่อไป ไม่ใช่ทำแล้วทิ้งนะ
- เมื่อเจอ bug ต่าง ๆ ทั้งจากการพัฒนา ทดสอบ หรือ บน production ก็ตาม ควรเขียน test case เพื่อ reproduce bug เหล่านั้น ก่อนทำการแก้ไข code ต่อไป มันคือ การเรียนรู็จากความผิดพลาด ไม่ใช่ผิดพลาดเรื่องเดิม ๆ ซ้ำ ๆ แต่เปลี่ยนแค่ data นะ !!
- ทุกครั้งที่ทำการ commit code ให้ลองทำการ run test ดูก่อนแบบอัตโนมัติดู เช่น run unit test เป็นต้น ถ้าไม่ผ่าน ก็ไม่ให้ทำการ commit เป็นต้น รวมทั้งยังเอา test ต่าง ๆ ไป run ใน pipline ของ CI/CD ด้วย
- Code/test coverage ไม่ได้บอกอะไรเลย เป็นเพียงผลพลอยได้จากการเขียน test เท่านั้น
สุดท้ายเดี๋ยวนี้ เราให้ Generative AI เข้ามาช่วยเขียน test case ให้ได้อีกด้วย
ก็ช่วยเพิ่มทางเลือกในการเขียน test ให้สะดวกขึ้น
แต่ก็ยังจำเป็นที่ต้องตรวจสอบด้วยคนด้วยเสมอ (Trust but Verify)
ดังนั้น test case ต่าง ๆ ควรมีความน่าเชื่อถือ
ทำงานได้อย่างรวดเร็วตามที่หวัง หรือ เหมาะสมกับระบบนั้น ๆ
ครอบคุลมใน business logic/use case ต่าง ๆ ที่จำเป็น
คำถามสุดท้ายคือ
การทดสอบที่คุณสร้างขึ้นมานั้น ได้เพิ่มความเชื่อมั่นหรือไม่ ?
ผลการทำงานของระบบงาน มีปัญหาน้อยลงไหม ?