Quantcast
Channel: cc :: somkiat
Viewing all articles
Browse latest Browse all 1997

บันทึก :: ว่าด้วยเรื่องของการทดสอบ (Testing)

$
0
0

Screen Shot 2559-01-28 at 6.28.26 PM

Screen Shot 2559-01-28 at 6.28.26 PM ผมเชื่อว่าในปัจจุบันเรื่องของการทดสอบ (Testing) เป็นสิ่งสำคัญของการพัฒนา software ยิ่งเป็น developer ด้วยแล้ว ต้องสามารถทดสอบสิ่งที่สร้างได้เสมอ เป็นแนวทางหนึ่งสำหรับการเป็น developer ที่ดีกว่าเดิม (Better Developer) ดังนั้นมาทำการสรุปเกี่ยวกับการทดสอบ (Automated testing) ว่ามันเป็นอย่างไรบ้าง

การทดสอบมันคือ เครื่องมือการออกแบบชนิดหนึ่ง

ผมเชื่อว่า code ที่มันทดสอบยาก มันมักจะยากต่อการอ่าน ทำความเข้าใจ มันมักจะยากต่อการดูแลรักษา ดังนั้นสิ่งหนึ่งที่ต้องท่องเอาไว้เสมอก็คือ Developer ที่ดีควรเขียน test เพื่อทดสอบ code ของตัวเองเสมอ ถ้ามันเขียนยาก มันแสดงว่า สิ่งที่คุณเขียนมันน่าจะมีปัญหานะ (Smell)
แต่ไม่ได้หมายความว่า การที่จะเป็น Developer ที่ดีจะต้องเขียน test นะ แต่สิ่งที่ต้องการบอกก็คือ Developer ที่ดีจะเขียน code ที่ง่ายต่อการทดสอบ ขอให้เข้าใจตรงกันนะ
ดังนั้น ถามตัวเราเองสิว่า Code ที่เราเขียนนั้น มันง่ายต่อการทดสอบหรือไม่ ? ถ้าตอบว่าใช่ ลองถามต่อไปสิว่า สามารถทดสอบได้บ่อยเท่าที่ต้องการหรือไม่ ? หรือทดสอบในทุก ๆ ครั้งที่ code มีการเปลี่ยนแปลงนั่นเอง !! ถ้า code มันยากต่อการทดสอบ แนะนำให้ทำการ refactor code เสียแต่เนิ่น ๆ พร้อมกับเขียน test ตามไปด้วย แล้วมันจะนำไปสู่การออกแบบที่ดีกว่าเดิมแน่นอน แสดงดังรูป Screen Shot 2559-01-28 at 6.44.07 PM

ให้เน้นไปที่ Unit testing ก่อนเสมอ

จากเรื่องของ Pyramid Testing นั้น ให้เน้นไปที่ Unit testing ก่อนเสมอ เนื่องจากมันทำให้เรารู้ และ เข้าใจว่า เรากำลังทำอะไรอยู่ เนื่องจากมันทำงาน หรือ ทำการทดสอบได้อย่างรวดเร็ว เนื่องจากเราสามารถรู้ผลการทำงานจากการเปลี่ยนแปลงได้เลย เนื่องจากมันทำให้เรารู้ว่าพฤติกรรมการทำงานมันถูกหรือไม่ ? pyramid (1) แต่ unit test และการทดสอบพฤติกรรมการทำงาน มันไม่ใช่ feature นะ ดังนั้น การทดสอบควรที่จะมีการทดสอบในระดับ feature หรือในมุมมองของผู้ใช้งานด้วย ไม่เช่นนั้น Developer จะไม่สนใจในภาพใหญ่ ซึ่งเป็นความเข้าใจที่ผิดอย่างมาก ดังนั้น Developer ควรเข้าใจภาพนี้อย่างมาก Screen Shot 2559-01-28 at 5.47.55 PM ในการเขียนชุดทดสอบ Unit test นั้น ควรเริ่มจาก test case ที่ง่าย ๆ และ เป็น Happy case หรือกรณีที่มันเกิดขึ้นอยู่อย่างเสมอ จากนั้นจึงไปเขียน test case อื่น ๆ เพื่อทำให้เรามั่นใจ ในสิ่งที่กำลังสร้างอยู่อย่างเสมอ จำนวนของ test case มันขึ้นอยู่กับความเชื่อมั่น ของ developer ของทีม ของคนอื่น ๆ ดังนั้นจงสร้างความเชื่อมั่นเหล่านี้ขึ้นมากัน
จงเริ่มสร้างได้แล้วนะครับ !!

Monitor/Measure Everything

ในระบบที่ developer พัฒนาอยู่นั้น คุณมี log หรือไม่ ? คุณมีการ monitoring ในระดับ application หรือไม่ ?
แต่เพียงแค่มีมันยังไม่พอนะ สิ่งต่าง ๆ เหล่านี้มันดีหรือไม่ ?
ถ้าคิดว่ามันดี เมื่อเกิดปัญหาขึ้นมา ทั้ง log และระบบ monitoring มันช่วยระบุจุดของปัญหาหรือไม่ ? ถ้าตอบว่า ไม่ ... มันคือสิ่งที่คุณต้องแก้ไข และ ปรับปรุงแล้วนะ

เน้นเรื่องของการทำงานร่วมกัน (Collaboration)

ในการพัฒนา software นั้น เป็นสิ่งที่ต้องทำงานเป็นทีม หรือ ใหญ่กว่านั้น แน่นอนว่า ย่อมมีคนทำงานมากกว่า 1 คน มีคนเข้า และ ออก อยู่อย่างสม่ำเสมอ
ดังนั้นสิ่งที่คุณกำลังสร้างมานั้น ต้องเอื้อต่อการทำงานเป็นทีม ต้องเอื้อต่อการทำงานร่วมกัน
บางคนบอกว่า เราก็มีเอกสารต่าง ๆ มากมายนะ ทั้ง Requirement specification ทั้ง Design specification ทั้ง Database design ทั้ง Activity diagram ทั้ง Class diagram ทั้ง test case ทั้งหมดที่อยู่ใน Spreadsheet แต่คำถามที่ต้องตอบ คือ เอกสารเหล่านี้มันน่าเชื่อถือหรือไม่ ? เอกสารเหล่านี้มันคือข้อมูลล่าสุดหรือไม่ ? ถ้าตอบว่าเชื่อถือ และ มันคือข้อมูลล่าสุดก็ดีมาก ๆ แต่เท่าที่ผ่านมา พบว่า เอกสารเหล่านี้ทำเพื่อให้มี !! ดังนั้น เชื่อถือไม่ได้เลย ยิ่งเป็น developer ด้วยแล้ว ไม่ชอบอ่าน และ ทำเอกสารเลย !! ดังนั้น สิ่งที่จะช่วยให้ devleoper ทำงานร่วมกันได้ง่ายคืออะไรล่ะ ? หนึ่งในนั้น น่าจะเป็นชุดการทดสอบแบบอัตโนมัติ เพียงแค่ run test ทั้งหมด ก็รู้ว่า สิ่งที่สร้าง สิ่งที่แก้ไข มันทำงานถูกหรือไม่ เป็นแนวคิด แนวทางที่น่าจะเพิ่ม productivity ใช่ไหม ? ส่วนตัวผมคิดว่า ใช่
ยิ่งถ้าชุดการทดสอบแบบอัตโนมัติ มีการตั้งชื่อที่ดีแล้ว มันก็อาจจะกลายเป็นเอกสารที่มีชีวิต และ เป็นข้อมูลล่าสุดเสมอ ฟังแล้วดูดีนะ ดังนั้นลองลงมือทำดูสิครับ รออะไรกันอยู่ !!

สุดท้ายเป็นเรื่องของความเร็วในการทำงาน (Speed)

สำหรับ developer หรือ คนที่ไม่เคยเขียน test มักจะบอกว่า ถ้าเขียน test แล้วมันจะทำให้การพัฒนาช้าลง ตอบได้เลยว่า ใช่แล้ว แต่มันไม่ได้ลด productivity นะ !! มันเป็นธรรมดาของการเรียนรู้ในสิ่งใหม่ ๆที่คุณจะต้องช้าลง แต่สิ่งที่คุณจะได้รับกลับมาก็คือ productivity ที่ดีขึ้นกว่าเดิม ลดการทำซ้ำ ๆ ลดความผิดพลาด รู้ความผิดพลาด ไม่ต้องมาเสียเวลา debug code ไม่ต้องเสียเวลามาดู log ไม่ต้องมาเสียเวลาทดสอบ
นั่นแสดงว่า มันไม่ได้ลดความเร็วของการพัฒนาเลยนะ เผลอ ๆ มันกลับทำให้คุณเร็วขึ้น และ productivity สูงขึ้นอีกด้วย
แต่ก่อนอื่น ให้เริ่มศึกษา ให้เริ่มลงมือทำ และ เรียนรู้
วันนี้ code ที่คุณเขียน มันง่ายต่อการทดสอบหรือไม่ ?

Viewing all articles
Browse latest Browse all 1997

Trending Articles