เรามักได้ยินว่า developer
ควรเขียน code ที่อ่านง่าย
ควรเขียน code ที่ดูแลรักษาได้ง่าย
ควรเขียน code ที่ทดสอบได้ง่าย
แต่มันไม่ใช่เรื่องง่ายเลยที่จะเขียน code แบบนั้นขึ้นมา
ดังนั้นเรามาดูกันดีกว่าว่า code ที่มันตรงกันข้ามเป็นอย่างไร ?
และใครกันนะที่ชอบเขียน code แบบนี้ออกมา ?
มาดูกันว่า code แบบไหน ที่มันยากต่อการทดสอบ
เพื่อทำให้ developer ระมัดระวัง อย่าสร้างมันขึ้นมา
บางครั้งเราจะเรียก code เหล่านี้ว่า Code Smell
ซึ่งทำให้ยากต่อการทดสอบ หรือ เขียนชุดการทดสอบเป็นอย่างมาก
1. ชื่อของ test method/test case กับสิ่งที่อยู่ใน test body ไม่สัมพันธ์กัน
สำหรับคนที่เขียน test
จะรู้ว่าการตั้งชื่อ test case นั้นเป็นเรื่องที่ไม่ง่ายเลย
แต่มันช่วยทำให้เราเข้าใจว่า
สิ่งที่เรากำลังจะทดสอบ หรือ ปัญหาที่กำลังจะแก้ไขคืออะไร ทำงานอย่างไร
และจะต้องได้ผลลัพธ์ของการทำงานอะไรบ้าง
นั่นคือ เป็นสิ่งที่บ่งบอกว่า เราเข้าใจปัญหาที่กำลังจะแก้ไข
รวมทั้งบอกถึงการออกแบบการทำงานของระบบหรือไม่ ?
จากนั้นทำการลงมือเขียน code ตามชื่อ test case นั้น
ผลที่ตามมาก็คือ สามารถอ่านชื่อ test case แล้วเข้าใจได้ทันทีว่า
ในแต่ละ test case คืออะไร ทำงานอย่างไร
แต่ส่วนมากเราจะพบว่า
ชื่อ test case มักจะสวนทางกับสิ่งที่อยู่ใน test case !!
มันส่งผลให้ยากต่อการทำความเข้าใจอย่างมาก
นั่นคือ ต้องใช้เวลาเพิ่มขึ้นนั่นเอง
มันไม่ดีเลยนะครับ
2. ชอบสร้าง object ใหม่ ภายใน method !!
ถ้าเป็นภาษา Java ก็คือ new XXX() นั่นเอง
ถ้าเราพบเจอ code เหล่านี้จำนวนมาก
แสดงว่า code ของเรานั้นผูกมัดกันอย่างมาก (Tight coupling)
ผลที่ตามมาก็คือ ทดสอบได้ยากมาก ๆ
ตัวอย่างเช่น
ถ้าเป็นส่วนของการติดต่อ Database
ถ้าเป็นส่วนของการติดต่อผ่าน Web Service
คำถามคือ คุณจะทดสอบมันอย่างไร
ถ้ายังสร้าง object เหล่านี้ขึ้นมาทุกครั้ง
รวมทั้งต้องเรียกใช้งานไปยัง Database และ Web Service จริง ๆ เสมอ
ลองคิดดูสิว่า ถ้า Database และ Web Service มันล่มไป
คำถามคือ คุณสามารถทำการทดสอบระบบได้หรือไม่ ?
หรือสามารถพัฒนาระบบงานต่อไปได้หรือไม่ ?
ถ้าตอบว่า ไม่ได้
แสดงว่า คุณยังไม่สามารถจัดการกับ dependency ต่าง ๆ เหล่านี้ได้
นั่นคือ สะท้อนถึง code และวิธีการคิดของเรานั่นเอง
สามารถอ่านเพิ่มเติมในเรื่องการจัดการ Dependency ได้
ซึ่งจะทำให้ code ไม่ผูกมัดกันมากเกินไป (Loose coupling)
นั่นคือ ทำให้สามารถทดสอบได้ง่ายขึ้น
3. ใช้ static field/property เยอะมาก ๆ
เนื่องจากเรากำลัง share state ของการทำงานให้กับ method และ class อื่น ๆ
นั่นหมายความว่า
ถ้าเรามี test case จำนวนมากที่ต้องทำการแก้ไขค่าจาก static field นี้
ผลที่ตามมาก็คือ ค่าหรือสถานะของ static field อาจจะผิดพลาดก็ได้
เรียกตัวแปรเหล่านี้ว่า Global variable หรือ Global state
ซึ่งมันน่ากลัวเป็นอย่างมาก !!
ดังนั้นแนะนำให้ ลด ละ เลิก นะครับ
4. ระวัง final class เมื่อใช้งาน Mockito !!
เนื่องจาก final class นั้นมีเป้าหมายเพื่อ
ไม่ให้ทำการ extends หรือ สืบทอด class นั้น ๆ ได้
ส่งผลทำให้เราไม่สามารถ mock มันได้
ยิ่งถ้าใช้ Mockito ด้วยแล้วจะเกิด error ทันที
ดังนั้นต้องคิดก่อนทำ ว่าสิ่งที่ทำนั้นเราต้องการอะไร อย่างไร
ปล.
ถ้าต้องการ mock จริง ๆ ก็สามารถทำได้นะ
แต่ต้องใช้ความพยายามเยอะหน่อย
เช่นสร้าง class มาหุ้ม final class เป็นต้น
5. ใน Constructor มีการทำงานเยอะมาก ๆ
เป็นสิ่งที่ควรระวังอย่างมาก
เพื่อไม่ทำให้กระบวนการสร้าง object มันยากและซับซ้อน
มิเช่นนั้น คุณจะไม่มีทางทดสอบได้เลยหรือทำได้ก็ยากมาก ๆ
ดังนั้น ลด ละ เลิก นะครับ
Reference Website
http://misko.hevery.com/2008/07/30/top-10-things-which-make-your-code-hard-to-test/
https://dzone.com/articles/5-easy-ways-to-write-hard-to-testcode
