จากการอ่านหนังสือ Growing Object Oriented Software Guided by Test
แล้วพบว่ามีแนวคิดหลายๆ อย่างที่มีประโยชน์
จึงได้ทำการสรุปเนื้อหาบางส่วนไว้อ่านบ้าง
โดยในส่วนแรกนี่ เกี่ยวกับแนวคิดต่างๆ เกี่ยวกับ Test Driven Development (TDD)
เริ่มจาก Golden Rule ของ TDD เลยก็คือ
Never write new functionality without a failing test
การ Refactoring ให้ Think local, Act local
Refactoring มันการเปลี่ยนแปลงโครงสร้างของ code ไม่ใช่พฤติกรรมนะ !!
ไปทีละก้าวเล็กๆ อย่างสม่ำเสมอ
เพื่อให้ดีขึ้นเรื่อยๆ ทำให้ code เข้าใจได้ง่าย และปลอดภัย
และส่งผลให้การดูแลรักษา code ทำได้ง่ายขึ้น
และการ Refactoring นั้นไม่ใช่การ redesign นะ เพื่อเปลี่ยนโครงสร้างใหญ่ๆ
ซึ่งตรงนี้เข้าใจผิดกันอย่างมาก
เนื่องจากวิธีการมันเป็น microtechnic ที่จะค่อยๆ ทำไปทีละเล็กทีละน้อย
เพื่อให้ระบบโตขึ้นไปเรื่อยๆ แบบถูกต้องและปลอดภัย ( incremental )
อีกเรื่องที่น่าสนใจก็คือ
มีหลายๆ ต่อหลาย project ที่มีการใช้แนวคิด TDD ไปใช้
โดยมี unit test ที่ดีมากๆ ครอบคลุมสุดๆ
แต่ระบบไม่สามารถที่จะใช้งานได้ หมายถึง ไม่สามารถ integrate เข้ากับส่วนอื่นๆ ของระบบได้ ??
จากปัญหาดังกล่าวทำให้หลายต่อหลายคน คิดว่า TDD มันไม่น่าจะใช้งานได้จริงนะ !!!
แล้วเราควรเริ่มยังไงดีล่ะ?
กลับมาคำถามง่ายๆ ว่า
เราจะเริ่มเขียน code ที่ตรงไหน อย่างไร ?
และที่สำคัญยิ่งกว่าก็คือ เราจะหยุดเขียน code เมื่อไร ?
จาก Golden rule ของ TDD คือ เริ่มจากการเขียน Fail test ก่อนสิ …
โดย test ที่เขียนขึ้นมานั้น ให้เริ่มเขียนด้วย Acceptance test นะ
เพื่อจะได้อธิบายว่า feature ที่เราต้องการสร้างเป็นอย่างไร
ดังนั้นถ้าเราสั่งให้ Acceptance test ทำงานแล้วยังไม่ผ่าน แสดงว่า feature นั้นยังไม่เสร็จหรือยังไม่ถูกสร้างขึ้นมา
แต่ถ้ามันผ่านแล้ว แสดงว่า feature ทำการพัฒนาเสร็จสิ้นแล้ว
จากการเขียน Accetance test ของแต่ละ feature ออกมาก่อน
ทำให้เห็นว่า ถ้าต้องการให้ feature นี้เสร็จจริงๆ ต้องเขียน code ในส่วนไหนบ้าง
ซึ่งให้สนใจเฉพาะ code ที่เกี่ยวข้องเท่านั้นนะ
ดังนั้นถ้านำเอา Acceptance test มาใส่ในแนวคิด TDD จะเป็นดังรูป
จากรูป ประกอบไปด้วย 2 ส่วนคือ
1. การทดสอบในรอบใหญ่ ซึ่งเริ่มด้วยการเขียน Failing acceptance test
ทำให้เรารู้ว่า feature ที่เราพัฒนานั้นมาสถานะเป็นอย่างไร
ช่วยทำให้เห็นว่าชุดของการทดสอบต่างๆ
สำหรับการทำ regression test เป็นอย่างไร
โดยในการทำงานเรามักแบ่ง acceptance เป็น 2 กลุ่มคือ
กลุ่มแรกคือ ส่วนที่เรากำลังทำงานอยู่ โดยไม่รวมอยู่ในขั้นตอนการ build ของระบบ
กลุ่มที่สอง คือ ส่วนที่ใช้ในการตรวจสอบว่า feature นั้นเสร็จหรือไม่เสร็จ โดยจะรวมอยู่ในขั้นตอนการ build
2. การทดสอบในวงเล็กของ TDD
ช่วยทำให้ทีมพัฒนารู้ว่าสิ่งที่ทำไปนั้น ไม่กระทบส่วนอื่นๆ นะ
หรือช่วยทำให้คุณภาพของ code ยังดีอยุ่เสมอ
และยังคงทำงานผ่านอยู่เสมอ
สุดท้าย แน่นอนว่าจะไม่ทำการ commit code ที่ยังทดสอบไม่ผ่านขึ้นที่เก็บ code ของทีมอย่างแน่นอน
ดังนั้นในการนำไปใช้งาน ต้องเลือกใช้ให้ถูกต้องด้วยนะเออ …
