ลำดับของการทดสอบส่งผลต่อประโยชน์ที่จะได้รับจาก 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 ออกมาดังนี้
เริ่มจากชุดของการทดสอบ

ทำให้ได้ production code แบบง่าย ๆ ดังนี้

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

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

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

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

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

เพื่อลดผลกระทบของการเปลี่ยนแปลงโครงสร้างของข้อมูล
เราจึงเปลี่ยนลำดับของการทดสอบใหม่
เริ่มจากการสร้างแต่ละ function ของ Stack ให้มันเสร็จไปเลย
โดยเริ่มจาก size() นี่แหละ อย่าเพิ่งไปสนใจ push, pop, peek มากนัก ดังนี้

สามารถเขียนชุดการทดสอบใหม่ได้ดังนี้

ทำให้เกิด production code ดังนี้

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

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

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

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

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

โดย code ของการฝึกอยู่ที่ Github::Kata Stack