ลำดับของการทดสอบส่งผลต่อประโยชน์ที่จะได้รับจาก TDD นะ

วันนี้ช่วงพักกลางวันจากงาน Conference JCSSE2016 ได้นั่งลองเขียน code ตามแนวคิด TDD (Test Driven Development) เพื่อทบทวนความเข้าใจในเรื่อง Small step (Increamental step) นั่นคือการสร้างระบบให้โตขึ้นอย่างต่อเนื่อง และ เสถียร ด้วยการเขียนชุดการทดสอบนั่นเอง โดยได้ฝึกตามบทความเรื่อง The Right Tests in The Wrong Order

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

เริ่มต้นฝึกด้วยการการเขียนชุดการทดสอบขึ้นมา

ซึ่งเป็นแบบ Small step ไปเรื่อย ๆ จนกว่าจะได้สิ่งที่ต้องการ โดยเรียงลำดับของการทดสอบที่แตกต่างกัน ซึ่งได้ผลลัพธ์ที่น่าสนใจดังนี้ ตัวอย่าง เป็นการพัฒนา Stack ขึ้นมาใช้เอง

• เป็น Stack ที่เก็บข้อมูลของตัวอักษร
• โดยจะมีการทำงานต่าง ๆ เช่น
  • push(String)
  • pop(): String
  • peek(): String
  • size(): int

จากนั้นจึงเริ่มการพัฒนาด้วยชุดการทดสอบดังนี้

1. เริ่มต้นจากการสร้าง Stack ว่าง ๆ ดังนั้นขนาดของ Stack มีค่าเป็นศูนย์
2. ทำการ push ข้อมูล 1 ตัวไปยัง Stack ดังนั้นขนาดของ Stack มีค่าเพิ่มขึ้น 1
3. ทำการ pop ข้อมูลออกจาก Stack ดังนั้นจะต้องได้ค่าที่ push ไปล่าสุด
4. ทำการ pop ข้อมูลออกจาก Stack 1 ครั้ง ดังนั้นขนาดของ Stack จะลดลง 1
5. ทำการดึงค่าล่าสุดใน Stack ด้วย peek()

เขียน code ตามแนวคิด Three rules of TDD ทำให้ได้ code ออกมาดังนี้ เริ่มจากชุดของการทดสอบ [gist id="a5b6f0e34e6f8c37843843acebfbc3ce" file="StackTest.java"] ทำให้ได้ production code แบบง่าย ๆ ดังนี้ [gist id="a5b6f0e34e6f8c37843843acebfbc3ce" file="StackString.java"]

แต่สิ่งที่ยังขาดอยู่คือ Stack ต้องรองรับการ push ข้อมูลที่มากกว่า 1 ตัว !!

คำถามคือ ถ้าเราต้องทำการเปลี่ยน code ใน class Stack จะกระทบเยอะไหม ? เช่นการเปลี่ยนชนิดข้อมูลของ input จาก String เป็น List ของ String

คำตอบที่ได้คือ เยอะมาก ๆ เกือบจะทั้งหมดยกเว้น size()

หมายความว่า ลำดับของการเขียน test ของเรานั้น มันไม่น่าจะถูกต้องแล้วนะ ถึงแม้ว่าจะเขียนแบบ Small step หรือค่อยเป็นค่อยไปแล้วก็ตาม !! มันยากดีนะ !!

ดังนั้นมาเริ่มต้นใหม่ดีกว่า

เพื่อลดผลกระทบของการเปลี่ยนแปลงโครงสร้างของข้อมูล เราจึงเปลี่ยนลำดับของการทดสอบใหม่ เริ่มจากการสร้างแต่ละ function ของ Stack ให้มันเสร็จไปเลย โดยเริ่มจาก size() นี่แหละ อย่าเพิ่งไปสนใจ push, pop, peek มากนัก ดังนี้ สามารถเขียนชุดการทดสอบใหม่ได้ดังนี้ [gist id="a5b6f0e34e6f8c37843843acebfbc3ce" file="StackTest2.java"] ทำให้เกิด production code ดังนี้ [gist id="a5b6f0e34e6f8c37843843acebfbc3ce" file="StackString2.java"] จากการเปลี่ยนลำดับของการชุดการทดสอบ พบว่า การพัฒนา code ราบรื่นมากยิ่งขึ้น รวมทั้งยังพัฒนา code แบบ Small step อยู่ เพียงแต่เปลี่ยนแนวคิดและแนวทางในการแก้ไขปัญหาเท่านั้นเอง โดยวิธีการนี้จะค่อย ๆ แก้ไขปัญหาแต่ละอย่างให้สำเร็จก่อน จากนั้นจึงไปแก้ไขปัญหาอื่น ๆ ต่อไป

สุดท้ายแล้วอย่าลืมฟังเสียง feedback ที่ได้รับจาก code นะครับ (Listen the feedback from your code)

TDD จะมีประโยชน์มาก ๆ ถ้าแต่ละรอบของ Red-Green-Refactor มันสั้น รวมทั้งต้องรับฟัง feedback จากผลลัพธ์ที่ได้ในแต่ละรอบด้วย เพื่อทำให้เราเดินต่อไปได้อย่างถูกต้องและเหมาะสม

จงอย่ากลัวที่จะผิด จงอย่างกลัวที่จะพลาด แต่จงเรียนรู้จากความผิดพลาดเหล่านั้น จากนั้นลองนำแนวคิดและวิธีการอื่น ๆ มาใช้งาน

สิ่งที่ผมทำอยู่นั้นคือ การฝึกฝนเพื่อให้ชำนาญ แต่มันจะไม่มีประโยชน์อะไรเลย ถ้าคุณไม่นำประยุกต์ใช้งานกับ production code โดย code ของการฝึกอยู่ที่ Github::Kata Stack