Test Driven Development (TDD) คืออะไร ?

วันนี้เราจะมาพูดถึง Test Driven Development (TDD) ซึ่งเป็นรูปแบบการพัฒนาซอฟต์แวร์ที่เราจะต้องสร้าง test ขึ้นมาก่อน แล้วจึงค่อยเริ่มเขียนโค้ด เรามาดูกันว่าวิธีแบบนี้มันจะมีข้อดีข้อเสียอะไรบ้าง ทำไมคนถึงได้นิยมกันนัก ?

ปัญหา

ไม่ว่าเราจะเป็น programmer หรือ front-end engineer เวลาเราเขียนโค้ด เราก็มักจะพบปัญหาเหล่านี้ในการทำงานอยู่เสมอ

  • เจอ bug ที่หลุดรอดสายตาเราไปได้ กว่าจะรู้ตัวก็ตอนส่งให้ tester ดูแล้ว
  • ที่แย่กว่าก็คือ หลังจากที่แก้ bug นั้นไปแล้ว พอส่งงานไปให้ตรวจอีกที tester กลับไปเจอ bug ตัวใหม่ ที่ตอนแรกยังไม่มี พูดง่ายๆ ก็คือ อุตส่าห์แก้ได้แล้ว ดันไปกระทบโค้ดอีกส่วนจนทำให้เกิด bug ใหม่นั่นเอง
  • bug ที่เจอนั้นเกิดได้จากหลายสาเหตุ เราต้องมานั่งไล่โค้ดทีละส่วนๆ กว่าจะเจอสาเหตุ

เชื่อว่าแทบทุกคนคงจะเคยเจอปัญหาเหล่านี้กันมาบ้าง ด้วยเหตุนี้เอง จึงเกิดแนวคิดการเขียนโค้ดที่เรียกว่า Test Driven Development (TDD) ขึ้นมา

Test Driven Development (TDD) คืออะไร ?

อย่างที่เกริ่นไปคร่าวๆ แล้วครับว่าการเขียนโค้ดแบบ TDD นั้น เราจะต้องเขียนโค้ดสำหรับ test ขึ้นมาก่อน แล้วค่อยเขียนโค้ดที่จะทำงานจริงๆ ทีหลัง หากโค้ดของเราทำงานได้ถูกต้อง เราก็จะสามารถรัน test นั้นผ่าน

ในการทำ TDD เรามักจะแยกการ test ออกเป็นกลุ่มย่อยๆ หรือจะแยกตาม feature เล็กๆ ก็ได้ครับ เวลาอยู่ดีๆ test ไม่ผ่านขึ้นมา เราก็จะหาสาเหตุได้ง่าย พอเราแยกการ test ออกเป็นส่วนๆ ได้แล้ว ก็ให้เราทำตามขั้นตอนดังต่อไปนี้เลยครับ

1. สร้าง Test ขึ้นมาก่อน

ก่อนอื่นให้เราดูว่า product ของเรานั้นจะต้องทำอะไรได้บ้าง แล้วจึงเขียนโค้ดสำหรับ test สิ่งเหล่านั้นขึ้นมาเพื่อตรวจสอบว่ามันทำงานได้ผลลัพธ์ที่ถูกต้องแล้วหรือยัง โดยขั้นตอนการเขียนโค้ดสำหรับ test นี้ เราอาจจะใช้ framework สำหรับ test โดยเฉพาะเข้ามาช่วยก็ได้ครับ

2. ลองรัน Test => ไม่ผ่าน

จากนั้นให้เราลองรัน test เหล่านั้นเลย ซึ่งแน่นอนว่าผลที่ได้นั้นควรจะไม่ผ่านทั้งหมด เพราะเรายังไม่ได้เริ่มเขียนโค้ดจริงๆ เลย จะว่าไปแล้ว ขั้นตอนนี้ก็เหมือนกับการ test การเขียน test ของเราอีกทีนั่นเองครับ เราจะได้มั่นใจว่ามันไม่ได้ test ผ่านเลยตั้งแต่แรกนะ

3. เริ่มเขียนโค้ดจริงๆ

ทีนี้ก็มาถึงขั้นตอนการเขียนโค้ดจริงๆ ซะทีครับ ในขั้นตอนนี้เราจะไม่ซีเรียสว่าโค้ดที่เขียนนั้นจะต้องสวยหรูอะไร ตรงกันข้าม เราจะเขียนแบบเอาแค่ test ให้ผ่านก่อนเท่านั้นครับ

4. รัน Test อีกที => ผ่าน

เมื่อคิดว่าน่าจะผ่านแล้วก็ให้ลองรัน test ดูอีกทีครับ ถ้าผ่านได้หมดก็แปลว่าเรามาถูกทางแล้ว แต่ถ้ายังมี test case ไหนไม่ผ่านอยู่ ก็ให้ย้อนกลับไปขั้นตอนที่ 3 ครับ

5. ปรับโค้ดที่รันผ่านแล้วให้ดีขึ้น

แม้จะรัน test ผ่านแล้วก็ไม่ได้แปลว่าจะเอาโค้ดนั้นไปใช้ได้เลยนะครับ เพราะก่อนหน้านี้เราแค่เขียนแบบลวกๆ เอาแค่พอผ่านก่อนเท่านั้น ในขั้นตอนนี้เราจะมาปรับโค้ดเดิมของเราใหม่ครับ โดยจะเน้นไปที่การลบโค้ดที่ซ้ำซ้อนออก ปรับการเขียนโค้ดให้อ่านง่าย จะได้สะดวกหากมีการแก้ไขในภายหลัง รวมไปถึงการปรับในเรื่องของประสิทธิภาพให้ดีขึ้นด้วยครับ เมื่อเสร็จเรียบร้อยแล้ว เราก็จะเริ่มขั้นตอนที่ 1 ใหม่สำหรับส่วนต่อๆ ไป ให้เราทำวนไปแบบนี้จนครบทุกๆ ส่วนตามที่ได้แยกเอาไว้ครับ

แล้วอย่างนี้งานไม่เสร็จช้าลงหรอ ?

เชื่อว่าแทบทุกคนคงจะสงสัยว่า อ่าว! ถ้าต้องมาเขียน test ก่อนถึงจะลงมือเขียนโค้ดจริงๆ แล้วอย่างนี้งานไม่เสร็จช้าลงหรอ ? แน่นอนว่าฟังดูแล้ว การทำ TDD ดูเหมือนจะใช้เวลาในการพัฒนามากขึ้นกว่าเดิม แต่จริงๆ แล้วมันไม่ใช่เลย เพราะว่า…

เขียนโค้ดได้อย่างมั่นใจ

เมื่อเรามี test แล้ว เราก็จะเกิดความมั่นใจในการเขียนโค้ดมากขึ้นครับ เวลาเพิ่ม feature ใหม่ๆ เข้าไป เราก็ไม่ต้องมากังวลว่าไอ้ที่ได้ทำไปแล้วมันยังทำงานได้ปกติดีอยู่หรือเปล่า เพราะเราสามารถรัน test ซ้ำได้เรื่อยๆ ครับ

Debug ง่ายขึ้นมาก

เนื่องจากเราแบ่งการ test ออกเป็นส่วนย่อยๆ เวลารัน test ไม่ผ่าน เราก็จะรู้ได้ทันทีเลยว่าส่วนไหนที่ทำให้มัน test ไม่ผ่าน ทำให้ไม่ต้องมาเสียเวลาไล่โค้ดทั้งหมดครับ

Requirement ไม่ตกหล่น

เนื่องจากการทำ TDD นั้น เราจะต้องให้ความสำคัญกับ requirement ของ product เป็นพิเศษ การเขียนโค้ดจึงมีจุดมุ่งหมายที่ชัดเจนมากขึ้น คือต้องตอบโจทย์นั้นให้ได้นะ ไม่งั้น test ไม่ผ่าน การเขียนโค้ดไม่ตรงตาม spec จึงเกิดขึ้นได้น้อยกว่า

TDD กับ Front-end Development

สำหรับ front-end engineer อย่างพวกเราก็สามารถนำ TDD มาใช้ได้เหมือนกันครับ โดยหลักๆ แล้วเราจะเอาไว้ test การเขียนโค้ด JavaScript นั่นเอง และหากใครยังมองภาพไม่ออกว่าหน้าตาของโค้ดสำหรับ test จะเป็นยังไง ก็ไม่ต้องกังวลไปครับ เพราะทุกวันนี้มี framework สำหรับ test ออกมาให้ใช้มากมาย โดยตัวที่น่าสนใจก็จะเป็น QUnit และ Jasmine ที่ออกแบบมาให้เราสามารถเขียน test ขึ้นมาได้ง่ายมากๆ เลย ลองไปเล่นกันดูนะครับ รับรอง TDD ไม่ยากอย่างที่คิด

(Visited 10,914 times, 9 visits today)

4 Responses to “Test Driven Development (TDD) คืออะไร ?”

  1. กำลังอยากลองเลยครับ …

  2. การเขียน เทสเคสจากการเอามาจาก customer requirement ควรจะใช้เทคนิคอะไรครับ Boundaly value analysis หรือ Equivalence partition ครับเพื่อ coverrage test ได้ทั้งหมดและก้กระชับที่สุด หรือวิธีไหนครับหรือขึ้นอยู่กับ plan of product นั้น?

  3. กำลังอ่านเลยพี่ เทพมาตอบไว้รอแล้ว

Leave a Reply