ในทุกวันนี้การเขียนพวก unit test/integration
หรือแม้แต่ acceptance test ล้วนแล้วแต่มีประโยชน์
รวมทั้งสามารถทำงานได้อย่างอัตโนมัติ
หรือว่าทำงานด้วยคำสั่งเพียงบรรทัดเดียว
แต่คุณเคยเข้าไปดูไหมว่าชุดของ test หรือ ชุดการทดสอบนั้น
- มันมีคุณภาพที่ดี สุขภาพที่ดี หรือไม่ ?
- มันมีประโยชน์สำหรับการพัฒนาระบบหรือไม่ ?
ลองมาดูตัวอย่างอาการที่ไม่ดีของชุดการทดสอบดีกว่า
ถ้าสิ่งที่คุณกำลังทำมีอาการดังต่อไปนี้
ก็ควรจะปรับปรุง แก้ไข ให้มันดีขึ้นได้แล้วนะครับ
อาการที่แรก จะเป็นดังนี้
$run all_test Test Result 0 test found 0 test failed
มันหมายถึงอะไรกัน ?
ปีนี้มันปี 2015 แล้วนะ คุณยังพัฒนาระบบงานโดยที่ไม่มีการเขียน test เลยหรือ ?
ถ้ายังไม่เขียน test เลย แสดงว่า
คุณเป็นนักพัฒนาที่ฉลาด และ เก่งมากๆ
แต่ในปัจจุบันระบบงานมันยิ่งซับซ้อนมากขึ้นเรื่อยๆ
ดังนั้นการพัฒนาระบบโดยไม่มีการเขียน test
หรือไปทำการทดสอบหลังจากการพัฒนาแล้ว
เป็นสิ่งที่น่ากลัวมาก และทุกๆ คนก็เจอมากับตัวเอง
ดังนั้น ปีนี้ 2015 แล้ว มาเริ่มทำในสิ่งที่ถูกต้อง และ ควรจะเป็นเถอะนะ
อาการที่ 2 ทำการ comment test หรือ ignore test เพียบเลย
$run all_test Test Result 500 test found 250 test ignored 0 test failed
ในกรณีมันน่าสนใจมากๆ เช่น
- ทำไมคุณทำการ ignore test ไป 250 test นะ ทำไมไม่ลบออกไป หรือว่าอย่างไร ?
- ทั้ง 250 test นั้นมันมีประโยชน์ หรือไม่ ?
- ทั้ง 250 test มันจำเป็นต้องมีอยู่หรือไม่ ? เพื่ออะไร ?
แน่นอนว่า ถ้านักพัฒนาเข้ามาดูในส่วนนี้
ก็ไม่มีเหตุผลที่จะต้องเข้าไปแก้ไข เพราะว่ามันถูก ignore ไว้ใช่ไหม ?
และก็ไม่รู้จะแก้ไขอย่างไรด้วย
และที่สนุกไปกว่านั้น ใน test เหล่านั้นมีคำว่า TODO, Underconstruction ไหมล่ะ ?
มันจะเขียนไปทำเผือกอะไร ?
มันช่วยทำอะไรให้ดีขึ้นไหม ?
ดังนั้นถ้า test ใดมันไม่มีประโยชน์แล้ว
ก็ให้ทำการลบไปเถอะครับ จะได้ไม่เป็นภาระต่อไป
คุณพัฒนาระบบงาน ก็ใช้ Source control กันยอยู่แล้ว
ก็ขอความกรุณาใช้ความสามารถของมันหน่อยนะครับ !!
หรือไม่รู้ว่าใน Source control เราสามารถย้อนไป version ก่อนๆ หน้าได้นะ
อีกสาเหตุหนึ่งของการ ignore test ก็คือ
การพัฒนาที่ยังไม่เสร็จ
การแก้ไข bug และ พวก hot fixed ต่างๆ
แต่ให้จำไว้ว่า
ถ้าคุณทำให้ test มัน failure ก็แก้ไขมันให้ผ่าน
ไม่ใช่มา ignore มันนะครับ
อย่าพูดคำว่า เดี๋ยวกลับมาแก้ไข
เพราะว่านั่นหมายถึงคุณจะไม่กลับมาแก้มันอีกเลย !!
อาการที่ 3 คือ ทำการทดสอบนานมากๆ
$run all_test ^C Exception :: UserInterrupt No test run :: User cancled after waiting 5 minutes for them ….
เมื่อใดก็ตามชุดการทดสอบทั้งหมดทำงานนานนนนนนนนมากๆ
นั่นหมายถึงชุดการทดสอบของคุณมีอาการป่วยที่หนักมากๆ
ลองคิดดูว่า feedback loop ที่ได้จากการทดสอบที่นานมันดีไหม ?
แล้วคุณจะใช้เวลาแก้ไขนานไหม ?
ดังนั้น การแก้ไขอาการนี้ทำได้ง่ายมากๆ คือ ทำให้มันเร็วขึ้นกว่าเดิม
และถ้าถามว่าเร็วแค่ไหม ตอบได้เลยว่า ก็เร็วขึ้นกว่าเดิมไงล่ะ
ผลจากการทดสอบที่ช้า มันส่งผลให้
นักพัฒนาทุกๆ คนไม่ run การทดสอบแล้วนะสิ เป็นกันหรือเปล่าครับ ?
และมันก็ส่งผลต่อระบบที่เราพัฒนาดังนี้
- นักพัฒนาอาจจะ check-in code ที่มัน fail เข้ามาใน Source control
- คนอื่นๆ ในทีมทำการ checkout code ออกไป
- เมื่อทำการ run test พบว่ามี failure test จำนวนมาก ซึ่งมันเสียเวลาไปโดยเปล่าประโยชน์
- ถ้าเป็นนักพัฒนาที่ดี จะทำการแก้ไข test เหล่านั้นให้ผ่าน ด้วยการหาจุดที่ผิดและแก้ไขมันซะ ซึ่งมันก็ทำให้เราเสียเวลาไปโดยเปล่าประโยชน์อีกนั่นแหละ
- แล้วถ้าเป็นนักพัฒนาที่ไม่ดีล่ะ คุณคิดว่าเขาเหล่านั้นจะทำอะไร ? ลองตอบกันนะ
- นักพัฒนาบางคนอาจจะเดินไปบอกคนที่ทำ failure test ให้ทำการแก้ไขซะ
ซึ่งนั่นก็ทำให้เกิดการ switch context ในการทำงานอยู่เรื่อยๆ มันก็เสียเวลาไปโดยเปล่าประโยชน์อีกแล้ว - ยังไม่พอ เมื่อทำการแก้ไข code แล้ว อาจจะเกิด conflict code อีก ก็ต้องมาเสียเวลา merge code กันอีก สนุกไหมล่ะ ?
ดังนั้น
ในแต่ละ test ควรที่จะเล็ก และ ทำงานเร็ว
ไม่เช่นนั้น คุณจะเสียเวลาไปโดยเปล่าประโยชน์
เช่นถ้าทีมมีข้อตกลงว่า ก่อนที่จะทำการ check-in code
ต้องทำการ run test ก่อนเสมอ
ลองคิดดูสิว่าถ้ามันทำงานถ้า คุณจะต้องรอนานเพียงใด
แต่การทำงานที่รวดเร็วของ test มันก็ไม่ได้มาแบบฟรีๆ นะ
และไม่ได้มาแบบง่ายๆ เลย
เนื่องจากยิ่งระบบของคุณใหญ่ขึ้น จำนวนของ test ก็เยอะขึ้น
แน่นอนว่าต้องใช้เวลาทดสอบนานขึ้น
ดังนั้น คุณก็ต้องลงทุน ลงแรง ในการทำให้การทดสอบมันเร็วด้วย
แล้วทำอย่างไรดีล่ะ ?
ง่ายๆ คือทำให้มันสามารถทำงานได้ดีไงล่ะ
ดังนั้น ถ้ามี test ไหนที่มีปัญหา ให้ทำการแก้ไขซะ อย่าไปหนีปัญหา
ถ้ามีการ comment หรือ ignore test แล้ว
ให้ทำการลบ หรือ เขียนมันใหม่ซะ
แต่ถ้าในระบบงานของคุณไม่มี test ล่ะ คุณจะทำอย่างไรดี ?