วันนี้เห็นมีการพูดคุยเรื่อง Unit testing มันทำงานช้า
หรือใช้เวลาในการทดสอบนานๆ
จะต้องแก้ไขอย่างไรดี ?
ที่มา :: https://www.facebook.com/iicmaster
ที่มา :: https://www.facebook.com/pitsanu.s
โดยจาก post ทั้งสองก็มีคำแนะนำต่างๆ ดังนี้
- ใช้ Hardware ที่มีประสิทธิภาพสูงกว่าเดิมสิ ทั้ง CPU และ Memory
- ทำการหา test ที่มันช้า แล้วแก้ไขให้เร็ว หรือ แยกออกมาสิ
- ทำการ run test แบบขนานสิ
- ทำการ mocking/stub สิ
- ทำการลบ หรือ ignore test ไปสิ !!
เราลองมาพิจารณากันนิดหน่อยสิ ว่าจริงๆ แล้วปัญหามาอาจจะมาจากอะไรบ้าง ?
- ความเร็วของ test
- ความเร็วของการ build
1. ความเร็วของ test
เป็นการเข้าไปดูที่ code ของ test แต่ละตัว
เพื่อปรับปรุงให้แต่ละ test ทำงานได้รวดเร็วขึ้น
โดยปัญหาส่วนใหญ่มาจาก
- ในการทดสอบมีระบบ หรือ ส่วนที่เกี่ยวข้องเยอะมากๆ (dependency) ทำให้การทำงานช้า
- ทำการติดต่อไปยัง database จริง
- ทำการติดต่อผ่าน network
- ทำการอ่านเขียนไฟล์
- มีการใช้งานพวก Thread
- มาจาก Logging ดังนั้นในการทดสอบก็ปิด logging ไปซะ
- ในการทำสอบมีการ setup ข้อมูลเยอะเกินไป บางครั้งอาจจะไม่ถูกใช้ด้วย
- โครงสร้างของ test มันซับซ้อนมากเกินไป
- ใน test มีการทำงาน หรือ ทดสอบซ้ำซ้อน
ดังนั้นแก้ไขด้วยการแยกส่วนการทำงานแต่ละส่วนออกจากกันให้ได้ (Isolate)
และพยายามทำงานบน Local machine เท่านั้นนะ
เพราะว่า “Stay Local, Stay Fast” ครับ
รูปตัวอย่างของการตัดส่วนการใช้งาน Network ออกไป
2. ความเร็วของการ build
ให้ความสนใจกับขั้นตอนการ build ซึ่งคือการ run test ทั้งหมดนั่นเอง
ซึ่งสามารถแก้ไข หรือปรับปรุงความเร็วการทำงานได้เช่น
- ใช้เครื่องที่แรงๆ ทั้ง CPU, RAM และ I/O
- ทำการ run test แบบขนาน
- ใช้หลายๆ เครื่องในการ build
- ใช้ระบบ cloud ในการ build
- Build บน distributed system
รูปตัวอย่างของการ build บนระบบ Cloud
แต่ก่อนอื่นคุณต้องทำ profiling ของการ build ก่อนนะ
ว่าปัญหาจริงๆ นั้นเกิดขึ้นตรงไหน อย่างไรบ้าง ?
ตัวอย่างเช่น
จากนั้นก็ลงมือทำซะ อย่าปล่อยมันทิ้งไว้นาน
ไม่เช่นนั้นจะแก้ไขยากมากๆ ครับ
สุดท้ายแล้ว
มาปรับปรุงให้ test มันทำงานเร็วๆ
เนื่องจากจะทำให้เราได้ feedback loop ที่รวดเร็วขึ้น
เนื่องจากจะทำให้เราได้เรียนรู้อย่างรวดเร็วขึ้น
เนื่องจากจะทำให้เราแก้ไขปัญหาได้รวดเร็วขึ้น
มันจะทำให้คุณ และ ทีม ปรับปรุงประสิทธิภาพในการทำงานได้ดีขึ้น
แน่นอนว่า คุณจะ run test ได้บ่อยเท่าที่ต้องการ
และนั่นคือ เส้นทางของคำว่า คุณภาพ
