เมื่อแก้โปรแกรมเพียงเล็กน้อยแล้วส่วนอื่นเสียตาม การตรวจด้วยมือทุกครั้งอาจใช้เวลามาก Unit Test ช่วยตรวจพฤติกรรมของส่วนย่อย เช่น ฟังก์ชันคำนวณหรือการตรวจข้อมูล ด้วยผลที่คาดไว้ล่วงหน้า จุดประสงค์ไม่ใช่แทนการทดสอบทั้งหมด แต่ช่วยให้ทีมรู้เร็วเมื่อพฤติกรรมที่สำคัญเปลี่ยนไปโดยไม่ได้ตั้งใจ
เริ่มจากกติกาที่อธิบายได้ชัด
สมมติมีฟังก์ชันนับจำนวนอุปกรณ์ที่ยืมได้ กติกาคือรับจำนวนทั้งหมดและจำนวนที่ถูกยืม แล้วคืนจำนวนคงเหลือ ก่อนเขียนการทดสอบควรตกลงว่าค่าว่างหรือจำนวนติดลบต้องจัดการอย่างไร หากกติกายังคลุมเครือ การทดสอบที่ผ่านก็อาจยืนยันสิ่งที่ไม่ตรงความต้องการ ผู้พัฒนาและผู้รับผิดชอบงานจึงต้องคุยเรื่องผลลัพธ์ก่อน
เตรียมข้อมูล ทำงาน แล้วตรวจผล
รูปแบบที่ใช้กันมากคือ Arrange, Act, Assert เริ่มจากเตรียมข้อมูลและสิ่งจำเป็น เรียกส่วนที่ต้องการทดสอบ แล้วตรวจผลเทียบกับที่คาด ตัวอย่างสมมติ มีอุปกรณ์ทั้งหมดสิบชิ้นและถูกยืมสามชิ้น ควรเหลือเจ็ดชิ้น การแยกสามช่วงทำให้ผู้อ่านเข้าใจว่าตรวจเรื่องอะไร โดยไม่ต้องไล่อ่านรายละเอียดที่ไม่เกี่ยวข้อง
เลือกกรณีขอบเขต ไม่ใช่แค่กรณีสวยงาม
นอกจากข้อมูลทั่วไป ควรดูกรณีไม่มีรายการ ค่าเป็นศูนย์ หรือข้อมูลที่ไม่อนุญาตตามกติกา แต่ไม่จำเป็นต้องรวมทุกกรณีไว้ในการทดสอบเดียว ตั้งชื่อให้บอกสถานการณ์และผลที่คาด เช่น เมื่อจำนวนถูกยืมมากกว่าจำนวนทั้งหมด ต้องแจ้งข้อมูลไม่ถูกต้อง ชื่อที่ชัดช่วยให้รู้ปัญหาเร็วเมื่อผลทดสอบล้มเหลว
ลดสิ่งแวดล้อมที่ทำให้ผลแกว่ง
การทดสอบส่วนย่อยควรทำซ้ำได้โดยไม่ต้องพึ่งอินเทอร์เน็ตหรือฐานข้อมูลจริงโดยไม่จำเป็น หากผลขึ้นกับเวลาปัจจุบันหรือค่าที่สุ่ม ควรออกแบบให้ควบคุมข้อมูลเหล่านั้นในการทดสอบได้ ส่วนการตรวจว่าหลายระบบเชื่อมกันถูกต้องเป็นหน้าที่ของการทดสอบอีกระดับ อย่าใช้ผล Unit Test แทนหลักฐานว่าทั้งระบบทำงานครบ
เปอร์เซ็นต์ครอบคลุมไม่ใช่คำรับประกัน
Code Coverage ช่วยบอกว่าส่วนใดถูกเรียกผ่านระหว่างทดสอบ แต่ไม่ได้ยืนยันว่าเงื่อนไขที่ตรวจมีคุณภาพหรือครอบคลุมความเสี่ยงทั้งหมด ฟังก์ชันอาจถูกเรียกโดยไม่มีการตรวจผลที่สำคัญก็ได้ ควรอ่านว่าการทดสอบยืนยันพฤติกรรมใด และเพิ่มกรณีจากข้อผิดพลาดที่เคยพบจริง แทนการไล่เพิ่มตัวเลขเพียงอย่างเดียว
สำหรับทีมเริ่มต้น ลองเลือกส่วนที่กติกาชัดและเปลี่ยนบ่อยหนึ่งส่วน ทำชุดเล็กที่อ่านง่ายและรันได้รวดเร็ว เมื่อพบข้อผิดพลาด ให้สร้างกรณีที่แสดงปัญหานั้นก่อนแก้ แล้วใช้เป็นการตรวจซ้ำในอนาคต หากทดสอบล้มเหลว ควรตรวจว่ากติกาเปลี่ยนหรือโค้ดผิด ไม่รีบแก้ค่าคาดหวังเพื่อให้หน้าจอกลับเป็นสีเขียว
อ้างอิงหลักการจาก Microsoft: Unit Testing Best Practices ตัวอย่างอุปกรณ์เป็นสถานการณ์สมมติและไม่ได้ผูกกับภาษาโปรแกรมใด
