Test-Driven Development (TDD)
Test-Driven Development (TDD) คำนี้ คงได้ยินกันค่อนข้างบ่อย
บ้างก็ว่ามันคือการเขียน Test ทุกความน่าจะเป็น ก่อนเขียนโปรแกรมเลย
บ้างก็ว่ามันคือแค่การคิด Case ก่อนเขียนโปรแกรมจริง(coding)
แล้วจะสื่อสารคำจำกัดความของมัน เป็นภาษามนุษย์ยังไงดีหล่ะ ?
สรุปง่ายๆ ให้ได้ใจความ ก็คือ ให้เขียนโปรแกรมเพื่อ Test ก่อนจะเริ่มเขียน Code โปรแกรมจริง (Coding)
การทำ TDD ควรคิดก่อนว่า เราจะทำ Test เพื่อตรวจสอบปัญหาอะไร
และแยกสิ่งที่จะทำ Test ให้เป็นหน่วยย่อยๆ ที่ทำงานอย่างเดียวเท่านั้น
เพราะถ้าวันดีคืนดี เทสกันไม่ผ่านขึ้นมาเราก็จะหาสาเหตุได้ง่ายๆ
TDD ประกอบด้วย หลัก 3 ข้อและ6 ขั้นตอน
ส่วนที่ 1: Red(Fail)
1.Write your tests first.
ดูก่อนว่า Product ของเรานั้นทำอะไร หรือจะต้องทำอะไรได้บ้าง และเขียนเพื่อตรวจสอบส่วนใด
เราก็เขียนกันออกมาก่อนเลย โดยขั้นตอนการเขียนโค้ดสำหรับ test นี้ เราอาจจะใช้ framework สำหรับ test
ซึ่งภาษาโปรแกรมปัจจุบันมีมาให้ ก็ได้เหมือนกัน
2.Watch them fail.
ไม่ต้องคิดอะไรมาก ก็รันให้มัน fail ไปเลย
ส่วนที่ 2: Green(Pass)
3.Write just enough code to make those tests pass.
ดูส่วนที่ fail แล้วก็เขียน code( เท่าที่จำเป็นนะ) เพื่อให้มันเทสผ่านก็พอ
ที่บอกว่า เขียนเท่าที่จำเป็น เพราะว่าเรามีส่วนสุดท้าย ที่จะต้อง Refactor อยู่แล้ว
เพื่อไม่ให้ code ดูรก และซับซ้อนเกินไป
4.Test again.
เทสใหม่ (ซึ่งแน่นอน มันก็ต้องผ่านสิ !!!) แต่ถ้ายังมี test case ไหนยังไม่ผ่าน ก็ให้ย้อนกลับไปขั้นตอนก่อนหน้า
ส่วนที่ 3 : Refactor
5.Refactor.
แม้ว่าเราเทสกันผ่านแล้ว ก็ใช่ว่าเราจะนำ code นี้ขึ้น production ได้เลยนะ
เพราะอย่าลืมว่าก่อนหน้านี้เราเขียนเพื่อ พอผ่าน ดังนั้นขั้นตอนนี้เราจะมาปรับ code เรากันครับ
เพื่อให้ code อ่านง่าย ง่ายต่อการแก้ไขในภายหลัง
รวมไปถึงเพิ่มการปรับในเรื่องของประสิทธิภาพให้ดีขึ้นด้วย
6.Repeat.
ทำซ้ำแบบนี้วนไปเรื่อยๆ ปรับปรุงให้ดีขึ้นเรื่อยๆ
หรือแม้กระทั้ง maintain code เดิม
กรณีมีการเปลี่ยน business logic อีกด้วย
ในความเป็นจริง Programmer สามารถทำเอง กันได้ง่ายๆ แบบนั้นเชียวเหรอ?
ตอนเริ่มเขียน Test ใหม่ๆ ผมก็มีคำถามเกิดขึ้นมากมาย ไม่ว่าจะเป็น
- จะเขียนยังไง?
- รูปแบบการเขียน ต้องเป็นแบบไหน ?
- จะเขียนครอบคลุม ขนาดไหน?
- เวลาเขียนโปรแกรมแกรม ก็น้อยอยู่แล้ว แล้วจะมีเวลาทำเหรอ ?
ผมมั่นใจว่าคนเริ่มเขียน Test แรกๆ ก็คงมีคำถามเกิดขึ้นมากมายไม่ต่างกัน
ยิ่งไม่มีเวลา ยิ่งต้องเขียน Test
ใช่แล้ว อ่านกันไม่ผิดหรอกครับ “ ยิ่งไม่มีเวลา เรายิ่งต้องเขียน Test ”
ปัญหาสุดจะ Classic ที่เราเจอกันคือ ทีมยุ่งมาก ไม่ค่อยมีเวลาทำงานใหม่ๆ
เพราะมัวแต่ไป Fix bug , Fix Production issues
ซึ่งแน่นอนแหล่ะ เมื่อเกิด bug ขึ้นในระบบ เราย่อมใช้เวลา fix bug มากกว่าเวลาเขียนโปรแกรมจริงๆ แน่นอน !!!
ยิ่งพวก Legacy code เยอะๆ ยุ่งๆ วุ่นวายๆ ถ้าต้องมาไล่ code เหล่านี้หล่ะก็
“แม่มม ขอ เขียนใหม่เลยได้ไม๊” กันเลยทีเดียว เห็นด้วยใหมหล่ะครับ
“แล้วพวกเราหล่ะ เริ่มเขียน Test กันแล้วหรือยัง ?”
บทความต่อไป จะลองนำ Concept TDD มาประยุกต์ใช้กับการเขียนโปรแกรมจริงๆ ด้วย ภาษา Golang กัน
