Test Driven Development ภาคแนะนำ

     กลับมาแล้วฮ๊าล์ฟฟฟฟ หลังจากหายไปอย่างนาน เนื่องจากมีภาระกิจหลายอย่างที่จะต้องทำ ซึ่งเป็นผลพวงจากการทำงานแบบผลัดวันประกันพรุ่ง จนพอกพูนเป็นหางหมู ก็เลยต้องสะสางกันยกใหญ่ มาเข้าประเด็นวันนี้กันดีกว่า

     ไม่นานมานี้ มีรุ่นน้องที่รู้จักคนนึงเข้ามาปรึกษาผมว่า "ไม่ค่อยมั่นใจกับ Code ที่เขียน เหมือนรู้ว่ามันมี Bug อยู่ แต่หาไม่เจอ" จากที่น้องเล่ามา แวบแรกผมก็คิดในใจว่า "ก็เขียนให้มันดีหน่อยสิ" แต่หลังจากมานั่งคิดนอนคิดแล้ว ผมว่าคำว่า "เขียน Code ให้มันดี" เนี่ยยังต้องการคำจำกัดความเพิ่มอีกเยอะว่าอันที่จริงแล้วมันคืออะไร แล้วมันใช่วิธีแก้ปัญหาอันนี้จริงรึเปล่า หลังจากทบทวนตัวเองเป็นเวลาซักพัก ผมให้คำตอบน้องคนนั้นไปว่า ปัญหามันน่าจะอยู่ที่มุมมองและโปรเซสการเขียน Code โดยสาเหตุของปัญหาก็คือการที่ไม่มีเป้าหมายในการ Coding อย่างละเอียดมากพอและไม่สามารถวัดความสำเร็จของการเขียน Code ได้อย่างแท้จริง โดยปกติแล้วทางแก้ที่อาจจะดูเป็นคำที่ดูเชยไปหน่อยแต่ก็ยังคงใช้ได้เสมอคือ "คิดก่อนที่จะเขียน" และ "รอบคอบที่จะตรวจสอบ" แต่ทั้งนี้ทั้งนั้นมันก็มีเครื่องมีบางอย่างที่จะช่วยได้ สิ่งนั้นคือ Test Driven Development

     Test Driven Development (TTD) คือขั้นตอนในการพัฒนาซอฟท์แวร์วิธีหนึ่ง ซึ่งสามารถเพิ่มผลผลิต (Productivity) ของเหล่า Coder ทั้งหลายได้ โดยหากนำไปใช้อย่างชำนาญพอแล้วยังทำให้ลด Defects ได้เยอะเลยทีเดียว

     โดยวิธีการของ TTD นั้นแสนจะง่าย (จริงป่าววะ) มันคือการกลับหัว Software Development Process แบบเดิมที่แสนจะน่าเบื่อจาก Design - Code - Test เป็น Test - Code - Refactor อันแสนสนุกและท้าทายแทน ซึ่งใครจะเชื่อว่าไอ้การ "สลับตำแหน่ง" แค่เนี้ยมันจะช่วยให้เราสร้างซอฟท์แวร์ที่มีคุณภาพได้อย่างไม่น่าเชื่อ ถึงแม้ว่า Requirement จะมีการเปลี่ยนแปลง ทำให้เป็นที่ปวดเศียรเวียนเกล้าอยู่ตลอดเวลา สิ่งนี้จะช่วยให้เราไม่หลงประเด็นจากสิ่งที่ลูกค้าต้องการ โดยที่ค่าใช้จ่ายในการ Maintain หรือแก้ Defects ก็ต่ำกว่าด้วยเพราะมีกระบวนการตรวจสอบความถูกต้องที่ดีกว่า (Automate Test Suite) และเหนือสิ่งอื่นใดในการทำงาน Coder ทั้งน้อยใหญ่จะทำงานไปด้วยความ (เมา) มันส์ เนื่องจากรูปแบบการเขียนจะเต็มไปด้วยความท้าทาย เหมือนเล่นเกมส์และมีเป้าหมายที่แน่นอน (ว่ากุจะต้องเขียนแล้วให้ได้ผลแบบนี้นะ) โดยในบล๊อกนี้จะไม่กล่าวถึงโพรเซสปกติ เนื่องจากสามารถหาได้ทั่วไป ไม่อยากเขียนซ้ำกับคนอื่นให้รกพื้นที่อินเตอร์เนท หากแต่จะกล่าวแนะนำและชี้ให้เห็นความแตกต่างในแง่มุมของ Test และการแปลงจาก Requirement สู่ Test Case แทน เนื่องจากถ้าเอาทั้งโพรเซสมันเยอะ กุขี้เกียจครับ

     เนื่องจากกระบวนการแรกของการทำ TDD นั้นคือการสร้างกระบวนการทดสอบพฤติกรรมของระบบก่อน แต่ทั้งนี้ทั้งนั้นการรู้เรื่อง Requirement อย่างละเอียดจะนำไปสู่การคิด Test Fail ดังกล่าวได้อย่างสมบูรณ์ยิ่งขึ้น

1. เหนือสิ่งอื่นใดเราต้องทำการวิเคราะห์ Requirement ซะก่อน ซึ่งโดยปกติแล้ว SA หรือผู้ที่ได้รับมอบหมายให้ Design System จะทำการแตก Requirement เป็น Task ย่อย ซึ่ง "อาจจะ" สร้างปัญหาให้กับ Coder หาก Task นั้นถูกเขียนไม่ละเอียดพอ ดีไม่ดีก็เป็นที่ตัว Coder ซะเองที่อ่านไม่เข้าใจ เนื่องจากรูปแบบของ Task นั้นไม่ค่อยมีความเชื่อมโยงกับตัวระบบในรูปแบบที่จับต้องได้เท่าที่ควร สังเกตุได้จาก Task บางข้อเมื่อ Coder เขียนเสร็จ แต่ไม่รู้จะ Test ยังไง หรือ ไม่สามารถตรวจความก้าวหน้าของงานตัวเองได้อย่างชัดเจน เนื่องจาก

Task แค่บอกว่าเราควรทำอย่างไร แต่ไม่ได้บอกว่า เมื่อทำเสร็จแล้วงานควรจะออกมาเป็นอย่างไร 

2. ดังนั้นสิ่งที่ TDD พยายามจะบอกคือ พวกเมิงแตก Requirement เป็น Test แทนเถอะครับ ตอนแรกอาจจะขัดในการเปลี่ยนมุมมอง แต่เดี๋ยวก็จะเจ็บและชินไปเอง โดย Test ที่ดีนั้นจะต้องมีคุณสมบัติ  คือ เล็ก และ มีจุดประสงค์ในการทดสอบที่ชัดเจน
3. ให้ลองนึกภาพ Test เป็นเหมือน Blackbox หรือ เครื่องจักรโดเรม่อนอะไรซักอย่าง ที่ไม่ซับซ้อนคิดแค่ว่าใส่ Input แบบนี้ไป ควรจะได้ Output แบบไหนออกมา

โดยสิ่งเหล่านี้ (TDD) จะส่งผลให้เราสามารถแก้ปัญหาด้านบนได้ ไม่มากก็น้อย ซึ่งอันที่จริงแล้วในแง่การนำไปใช้จริง ผมยังไม่เคยผ่านองค์การที่นำมาใช้อย่างเต็มรูปแบบซักเท่าไหร่ จึงอาจจะยังไม่ค่อยเห็นภาพในบางมุม ถ้าใครมีคำแนะนำ หรือมีมุมมองอยากจะแบ่ง ก็เต็มที่เลยครับ