Test-Driven Development

หายหน้าหายตาไปนานพอสมควร วันนี้จะพูดถึงอีกเรื่องหนึ่งที่ผมกำลังศึกษาอยู่ นั่นคือ TDD หรือ  Test-Driven Development  เรื่องนี้เองก็ยังเป็นเรื่องที่ใหม่สำหรับผมอยู่พอสมควร ดังนั้นอาจจะมีจุดที่ผิดอยู่บ้าง ถ้าท่านใดมีความเห็นอย่างไรเชิญคอมเม้นท์ได้นะครับ

ขอเกริ่นนิดหนึ่ง ประมาณ 2-3 ปีที่แล้ว ในส่วนของฝ่าย Development ในบริษัทผมมีการทำอะไรแปลก ๆ อยู่อย่างหนึ่ง คือ การให้ Tester เขียนแผนการทดสอบในช่วงที่กำลังวางสเปคของโปรเจคอยู่ ซึ่งปรกติแล้วการเขียนแผนการทดสอบนั้นจะเขียนหลังจากได้สเปคมาแล้ว (เพราะว่าสเปคนั้นจะเปลี่ยนไปมาได้ตามความต้องการของลูกค้าและข้อจำกัดหลาย ๆ อย่าง) ผมคิดว่ามันเกิดจากช่วงนั้นกระแส TDD มันมาแรงในหมู่นักพัฒนา เขาก็เลยลองเอาวิธีมาปรับใช้ดู ผลคือ … ไม่ทราบเหมือนกันครับ แต่ว่าหลังจากนั้นแล้วก็ไม่มีโปรเจคไหนทำวิธีนี้อีก …

ผมไม่ได้บอกว่า  TDD มันไม่ดีหรือไม่เหมาะกับโปรเจคที่บริษัทผม แต่ผมคิดว่าวิธีการประยุกต์ใช้งาน concept  นี้นั้นมันผิดพลาดไปหน่อย … แต่ก่อนจะถึงว่ามันผิดอะไรยังไงผมขออธิบาย  TDD ตามที่ผมเข้าใจก่อนดีกว่าครับ

Test-Driven Development (หรือ TDD)

TDD เป็นหนึ่งในคอนเซพท์ตระกูล Extreme Programming (ผมเรียกของผมว่าการโปรแกรมแบบสุดโต่ง) หรือ XP โดยจะโดยใช้การทดสอบเป็นศูนย์กลางของการพัฒนาโปรแกรม

ในการพัฒนาโปรแกรมในแบบดั้งเดิมนั้นเรามักจะเขียนสเปคของโปรแกรมก่อน จากนั้นก็ลงมือเขียนโค๊ด แล้วตามด้วยการทดสอบ ซึ่งในการทดสอบนั้นก็จะแบ่งออกเป็นการทดสอบหน่วยย่อยของโปรแกรม (Unit Test) การทดสอบการทำงานร่วมกัน (Integration Test) การทดสอบฟังก์ชั่นการใช้งาน (Functional Test) และการทดสอบเพื่อการยอมรับของผู้ใช้ (User Acceptance Test หรือ  UAT) ซึ่งแผนการทดสอบนั้นก็จะเขียนหลังจากที่เขียนโค๊ดเสร็จแล้ว

แต่สำหรับ TDD นั้นจะโยกเอาการเขียนแผนการทดสอบหน่วยย่อยของโปรแกรม (Unit Test – ผมเคยเขียนถึงไปนิดหน่อยก่อนหน้านี้) ออกมาทำก่อนการเขียนโค๊ด เป็นส่วนหนึ่งของการร่างสเปคของโปรแกรมไป และการเขียนโค๊ดนั้นก็จะทำโดยมีเจ้าแผนการทดสอบนี้เป็นหลัก พูดกันง่าย ๆ คือเราจะเขียนโค๊ดเพื่อให้ผ่านการทดสอบ Unit Test ดังนั้นเวลาทำเราก็จะทำๆ เทสต์ ๆ เป็นระยะ ๆ เพื่อให้มั่นใจได้ว่าโปรแกรมเรานั้นทำงานได้อย่างถูกต้องนั่นเอง

บางคนอ่านแล้วคงคิด เฮ้ย ถ้าทำ ๆ เทสต์ ๆ แบบนี้มันไม่เสียเวลาแย่เหรอ ? ถ้าเป็นการทดสอบด้วยมือนั้นคงเป็นอะไรที่เสียเวลาสุด ๆ ครับ แต่เราอยู่ในศตวรรษที่ 21แล้ว การทำทุกอย่างด้วยมือคงเป็นเรื่องประหลาด ปัจจุบันนี้เรามีการใช้สิ่งที่เรียกว่า Unit Test Framework อย่างเช่น xUnit (เปลี่ย x เป็นตัวย่อของภาษาที่คุณชอบนะครับ) ซึ่งเราจะใช้ Framework นี้ในการเขียนโปรแกรมสำหรับทำ  Unit Test  โดยเฉพาะ โดยเราสามารถใช้โปรแกรมนี้เพื่อทำการทดสอบแทนที่จะมาสั่งพิมพ์ออก Console หรือ  Debug ด้วยมือ ข้อดีคือโปรแกรมทดสอบนี้รันได้บ่อยเท่าที่ใจปราถนา และเมื่อจบโปรเจคไปแล้วเรายังสามารถนำโปรแกรมทดสอบนี้ไปใช้งานได้ ดังนั้นเมื่อมีการเพิ่มเติมหรือขยายตัวผลิตภัณฑ์เรายังสามารถใช้โปรแกรมทดสอบนี้ในการทดสอบได้โดยที่ไม่ต้องเขียนใหม่ทั้งหมด

ตัว Unit Test Framework นี้ผมจะพูดถึงในโอกาสถัดไปครับ

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

ประโยชน์ของ TDD นั้นก็น่าจะเป็นการรวมเอาการเขียนแผนการทดสอบหน่วยย่อยของโปรแกรมเข้าไปในสเปคของโปรแกรมด้วย (แน่นอนว่าคนเขียนก็ต้องเป็นสถปนิก (architect) ล่ะครับ) ทำให้ผู้เขียนโปรแกรมนั้นไม่หลงทิศทางเวลาเขียน และสามารถทดสอบโค๊ดของตัวเองได้บ่อยเท่าที่ต้องการ (แถมใช้เวลาน้อยกว่า) นอกจากนั้นโปรแกรมทดสอบก็ยังสามารถเอาไปใช้ทีหลังได้อีกด้วย

สุดท้ายนี้ สำหรับวิธีที่บ.ผมใช้นั้นมันผิดตรงไหนเนี่ย หลาย ๆ คนคงจับได้แล้ว ก็คือการเขียนแผนการทดสอบฟังก์ชั่นการทำงานเป็นส่วนหนึ่งของสเปค  ผมจะไม่บอกว่ามันไม่ใช่วิธีที่ผิดอะไร และที่จริงก็อาจจะเป็นเรื่องดีด้วยซ้ำ แต่ว่าในทางปฎิบัติมันเป็นเรื่องที่เป็นไปไม่ได้เลยครับที่จะทำแบบนั้น (ในขณะที่  spec ก็ยังคงเปลี่ยนไปเรื่อย ๆ) นอกจากนี้มันไม่มีประโยชน์ด้วย เพราะว่าแผนการทดสอบฟังก์ชั่นการใช้งานนั้นโปรแกรมเมอร์แทบไม่ได้ใช้เลยครับ จะไปใช้ในตอนที่ทำการทดสอบหลังจากส่งโค๊ดไปแล้วนู่น

ใส่ความเห็น

อีเมลของคุณจะไม่แสดงให้คนอื่นเห็น ช่องข้อมูลจำเป็นถูกทำเครื่องหมาย *

This site uses Akismet to reduce spam. Learn how your comment data is processed.