สัปดาห์ที่ผ่านมามีโอกาสแบ่งปันประสบการณ์เรื่อง การเขียน Unit test
โดยเป็นสิ่งที่นักพัฒนาทุกคนควรทำ
ถ้าเขียน code ได้แล้วก็เขียน Unit test ได้เช่นกัน
ที่สำคัญ code ของ Unit test นั้น
ต้องได้รับการดูแลเยี่ยง production code
นั่นคือ ต้องทำการดูแลและปรับปรุงให้ดีขึ้นอยู่เสมอ
มิฉะนั้นมันจะมาทำร้ายเราแน่นอน
สิ่งที่น่าสนใจมาก ๆ คือ เรื่องการเขียน Unit test ที่ดี
จึงนำมาสรุปไว้นิดหน่อย
ประกอบไปด้วย
1. Unit test ต้องทำงานได้อย่างรวดเร็ว
เหตุผลหลักของการเขียน Unit test คือ ต้องทำการทดสอบ มีประโยชน์เพื่อ ทำให้มั่นใจว่าสิ่งที่สร้างและเปลี่ยนแปลงทำงานได้อย่างถูกต้อง ทำให้มั่นใจว่าสิ่งที่สร้างและเปลี่ยนแปลงกระทบต่อส่วนการทำงานอื่น ๆ หรือไม่ ถ้าพบเจอปัญหาได้อย่างรวดเร็ว ก็จะทำการแก้ไขได้ทันที นั่นหมายความว่า ความเร็วในการทดสอบต้องเร็วมาก ๆ เพื่อให้ได้รับผลหรือ feedback ที่รวดเร็ว เพื่อทำให้เรามั่นใจ เพื่อทำ regression ซ้ำแล้วซ้ำเล่า เมื่อเรามั่นใจแล้ว คนอื่น ๆ ก็มั่นใจตามไปด้วย ที่สำคัญทำให้เรากล้าที่จะแก้ไข หรือ ปรับปรุง code ให้ดีขึ้นอีกด้วย ลองคิดดูสิว่า ถ้า Unit test ทำการทดสอบนาน ๆ แล้ว ยังจะมีใครมาเขียนหรือทดสอบกันไหม !! ดังนั้น พยายามแยกส่วนการทำงานต่าง ๆ ออกมาเป็นส่วนย่อย ๆ ไม่รวมเอาการทดสอบพวก UI, Network และ Database มาใส่ในชุดการทดสอบ Unit test อย่าทำการ sleep หรือ wait ในชุดการทดสอบ Unit testจำไว้ว่า ยิ่งทำการทดสอบ Unit test บ่อยมากเท่าไร ก็จะยิ่งได้รับประโยชน์จาก Unit test มากเท่านั้น
2. แต่ละ test case ต้องมีเป้าหมายในการทดสอบเดียวเท่านั้น
ในการแต่ละ test case นั้นต้องให้ผลออกมา fail หรือไม่ผ่าน เนื่องจากเป้าหมายหลักเพื่อออกแบบ test case ที่ช่วยหาข้อผิดพลาด หรือ ป้องกันข้อผิดพลาดนั่นเอง ดังนั้นชื่อของ test case ต้องอธิบายอย่างชัดเจน ว่าต้องการทดสอบอะไร ด้วยข้อมูลอะไร รวมทั้งความคาดหวังเสมอ ซึ่งความคาดหวังควรมีเพียงอย่างเดียวหรือเรื่องเดียวนั้นปล. ถ้าเขียน Unit test แล้วยังมานั่ง debug code แสดงว่า Unit test ยังใหญ่ หรือ ไม่ focus ในสิ่งที่ต้องการ ดังนั้นแทนที่จะ debug ก็ให้เขียน test case เพิ่มซะ
3. Unit test ต้องมีความน่าเชื่อถือ 100%
ไม่ว่าจะทดสอบที่ไหน ไม่ว่าจะทดสอบเวลาไหน ไม่ว่า network จะล่มไหม ไม่ว่า database จะพังไหม ถ้ามันเคยผ่านก็ต้องผ่านเสมอ ถ้ามันไม่ผ่านก็ต้องไม่ผ่านเสมอ ไม่ใช่ว่า บางครั้งผ่านบางครั้งไม่ผ่าน หรือดวงดีผ่านหรือดวงไม่ดีก็ไม่ผ่าน ถ้าเป็นแบบนี้จะไม่มีใครเชื่อถือ Unit test เลย สุดท้ายก็มองว่ามันคือสิ่งที่ไร้ประโยชน์มาเขียน Unit test กันเถอะนะ