Test Driven Development (TDD) 

TDD   คือ กระบวนการพัฒนาซอฟต์แวร์ ที่อาศัยหลักการทำซ้ำในวงจรพัฒนาที่สั้นๆ โดยสิ่งแรกที่ Developer จะทำคือเขียน automated test case (ที่จะ Fail) เพื่อที่จะกำหนดคุณสมบัติของฟังก์ชันใหม่ที่ต้องการ และจากนั้นจะใช้วิธีการเขียนโค็ดให้น้อยที่สุดที่จะผ่าน Test แล้วจึงค่อยปรับปรุงโค็ดให้ได้ มาตรฐาน กล่าวคือ ถ้าพูดภาษาชาวบ้านก็คือการ ทดลองเขียน Code ขึ้นมาโดยใช้ เคสตัวอย่างและจงใจให้มันผิดแต่แรกครับ เพื่อที่จะหาช่องโหว่ในตัวโปรแกรมและมาทำการแก้ไขให้ดูกระซับมากที่สุด 🙂

ประวัติของ TDD
Kent Beck ผู้คิดค้น TDD ซึ่งใช้กับ Extreme Programming ในปี 90 และเริ่มใช้ตัว TEST ที่สร้างขึ้นมาเอง  ต่อมา JUnit framwork พัฒนาโดย Beck และ Erich Gamma ในปี 97 ทำให้การเขียน TEST และเรียกใช้งานคำสั่ง TEST นั่นง่ายมากขึ้น และนับจากนั้น JUnit ก็ได้พัฒนาไปใช้กับภาษาอื่นๆ อีกหลายภาษาา เช่น .NET , C++ , Python , PHP เป็นต้น ซึ่งเป็นที่เรียกกันอย่างแพร่หลายในชื่อ xUnit Frameworks

เมื่อแนะนำตัวกันมายาวยืดมีแต่น้ำแล้วน่ะครับ ต่อมาเรามาเข้าเนื้อๆกันดีกว่าครับ !!

ขั้นตอนการทำ Test Driven Development หรือ TDD

1.) Quickly add a test หรือ การเขียน TEST CASE ขึ้นมา

2.)Run the tests หรือ การรัน TEST เพื่อให้เห็นว่าไม่สามารถรัน TEST CASE ได้ใหม่ หรือ เรียกง่ายๆว่า Run มันอยู่อย่างนั้นแหละ จนกว่าจะเจอบัค ฮุๆ…

3.)Update the code หรือ การแก้ไขโค็ดให้พอเท่าที่สามารถ TEST ได้

4.)Re-run tests หรือ การรัน TEST หรือเรียกภาษาชาวบ้านว่าการแก้ไขจนกว่าจะผ่าน TEST

5.)Refactor หรือการแก้ไขโค้ดดีไซน์ดีๆ และได้มาตรฐานและลบสิ่งที่เป็นการทำซ้ำที่ไม่จำเป็นออก

6.)Repeat ภาษาชาวบ้านเราก็คือการทำขั้นตอน 1 ถึง 5 ซ้ำใหม่นี่แหละครับ

ที่มาของรูปภาพ : http://www.ce.kmitl.ac.th/download.php?DOWNLOAD_ID=4194&database=subject_download

 

 

มาถึงตอนนี้ อาจมีหลายคนมีเครื่องหมาย ??? เกิดขึ้นบนหัวกันเป็นแถวและแทบจะตระโกนถามออกมาว่า แล้วอย่างนี้งานไม่เสร็จช้าขึ้นเหรอ ฟระ…. ? แต่เดี๋ยวกรุณาช้าก่อนครับ เรามาดูข้อดีข้อเสียของ Test Driven Development หรือ TDD

 

ข้อดีของ 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 ไม่ยากอย่างที่คิด

ข้อเสียของ TDD

                      หากแบ่งส่วนของโปรแกรมที่ไม่เหมาะสม เช่น ย่อยเกินไปก็จะเสีย Overhead ในการสร้าง automated test case เยอะ และถ้าหากแบ่งส่วนของโปรแกรมใหญ่เกินไป ก็จะทำให้สร้าง automated test case มีความซับซ้อน และมีความเสี่ยงที่จะเกิดความผิดพลาดที่ตัว Test Case เองโดยมีข้อสรุป ยิบย่อยดังนี้

                               1. ใช้เวลานานในการพัฒนา เพราะต้องใช้ในการพัฒนาโปรแกรมมาก

                               2. ต้องทำความเข้าใจ Code ที่มากขึ้นเพราะมีการทดสอบที่แตกต่างกันไป

                               3. มีราคาค่อยข้างสูงขึ้นในการทดลองกรณีที่ไม่สำคัญ

                               4. บางครั้งเสียเวลาไปกับการทดสอบกรณีที่ไม่สำคัญ

                               5. ประสิทธิภาพขึ้นอยู่กับประสบการณ์และวินัยของทีมพัฒนา

                               6.ยากที่จะนำเอา TDD ส่วนเดิมไปใช้ในการสร้างบนตัว Project ใหม่

                               7. ลดควาามสามารถในการเขียน Code อย่างรวดเร็วและเกิดข้อมูลที่ไม่จำเป็น

                               8. ความยากที่จะประเมินว่าเสียเวลาให้กับ TDD เท่าไหร่ หรือว่าช่วยประหยัดเวลาในกาารทำ TDD

                               9. ยากที่จะประเมินว่าเสียเวลาให้กับ TDD เท่าไหร่ หรือว่าช่วยประหยัดเวลาในการทำTDD

                               10. มีผลการทดสอบที่ลดลง หากมีโปรแกรมทำงานช้า

                               11. มีราคาในการติดตั้งที่สูง

 

 

อุ้ย….เกือบลืม นิดหน่อยน่ะครับดันลืมเขียนการ การทำTest Driven Development หรือ TDD มาซะยืดยาว แต่ดันลืมลงรูปตัวอย่างโครงสร้างของ TEST เรื่องสำคัญ ซะด้วย กราบขออภัยท่านผู้อ่านน่ะครับ 

ที่มาของรูปภาพ : http://www.somkiat.cc/tpse2014-test-driven-development/

 

 

ตัวอย่างของ TEST

 

ที่มาของรูปภาพ : http://www.ce.kmitl.ac.th/download.php?DOWNLOAD_ID=4194&database=subject_download

 

เขียน TEST ในตอนแรกของการ Run Test ควรจะ Fail จากนั้นจึงทำการแก้ไขโค้ดจนสามารถ TEST ได้

ที่มาของรูปภาพ : http://www.ce.kmitl.ac.th/download.php?DOWNLOAD_ID=4194&database=subject_download

และนี้คือสุดท้าย แล้วน่ะครับแถมเครื่องมือที่ใช้ใรการเขียน TEST เบื้องต้นกันไปเลย…..เป็นไงหล่ะ ใจดีสุดๆ

ที่มาของรูปภาพ : http://www.ce.kmitl.ac.th/download.php?DOWNLOAD_ID=4194&database=subject_download

 

 

” เหนืออื่นใด ต้องขอบคุณท่านผู้อ่านทุกท่านที่ยอมสละเวลาอันมีค่า เข้ามาอ่านบทความนี้ ทางกระผมหวังว่า บทความนี้จะเป็นประโยชน์ไม่มากก็น้อยแก่ผู้อ่าน “

 

 

 

อ้างอิง : http://www.somkiat.cc/tpse2014-test-driven-development/
 http://www.siamhtml.com/test-driven-development-introduction/
http://www.ce.kmitl.ac.th/download.phpDOWNLOAD_ID=4194&database=subject_download

• Line