เขียน Unit Test กันดี ๆ หน่อยนะ

สัปดาห์ที่ผ่านมามีโอกาสแบ่งปันประสบการณ์เรื่อง การเขียน 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 กันเถอะนะ