ปีนี้มีโอกาสไปพูดเรื่อง Test Driven Development (TDD)
ในงาน Thailand Practical Software Engineering 2014
โดยสิ่งที่ต้องการสื่อสารออกไปก็คือ ในปัจจุบัน TDD เป็นอย่างไร
การนำ TDD ไปใช้งานในภาพใหญ่
รวมทั้งประวัติความเป็นมา โครงสร้างของ test
และเครื่องมือต่างๆ ที่เกี่ยวข้อง

มีคนถ่ายรูปไว้ให้ด้วย ขอบคุณมากๆ ครับ


เริ่มต้นด้วยการนำ TDD ไปใช้ในงาน

ความเข้าใจผิดแรกๆ เลยก็คือ คิดว่าเป็นเพียง

  1. เขียน test ให้ fail  => RED
  2. เขียน code เพื่อให้ test ผ่าน => Green
  3. Refactor code เพื่อทำให้ code สะอาด เป็นขั้นตอนที่มักจะลืม หรือ ไม่ทำกันเลย
  4. และทำซ้ำในข้อแรกใหม่ วนแบบนี้ไปเรื่อยๆ

แต่ในการใช้งานจริงๆ คุณควรต้องเขียน End-to-End test หรือพวก Acceptance Test ก่อนเสมอ ดังรูป

Screen Shot 2557-08-21 at 9.07.00 PM

และเมื่อดูในระบบขนาดใหญ่ๆ ล่ะ จะนำไปใช้อย่างไร สิ่งที่แนะนำไปดังรูป

Screen Shot 2557-08-21 at 9.07.10 PM

ต่อจากนั้นเล่าถึงประวัติความเป็นมาของ TDD

โดยผมใช้ข้อมูลมาจาก C2=> Ten Years of TDD
ซึ่งจากประวัติความเป็นมานั้น จะพบว่ามีแนวคิดที่อยู่ด้านหลังของ TDD มากมาย
ตัวอย่างเช่น

  • Professionals test their code => คำถามที่น่าสนใจก็คือ คุณทำการทดสอบ code ที่คุณเขียนจริงๆ ไหม ?
  • Separate what from how => test จะบอกว่าระบบทำงานอะไร ส่วน code จะบอกว่าระบบงานทำงานอย่างไร ซึ่งต้องแยกออกจากกัน
  • Automated tests confirm features => ในการทดสอบต้องทำงานแบบอัตโนมัติ
  • TDD is change culture => มันคือการเปลี่ยนแปลงวัฒนธรรมของทีมกันอย่างมาก
  • Working is not enough => เพียงแค่ทำให้ระบบทำงานได้นั้นยังไม่เพียงพอ ยังต้องมีคุณภาพไปด้วยเสมอ
  • Focus on intent => ให้ความสนใจในสิ่งที่กำลังจะทดสอบ
  • Working system provides feedback => ระบบที่เราพัฒนาแล้วนั้นจะต้องบอกเราได้เสมอว่าสิ่งที่เราทำไปมันทำงานได้หรือไม่ได้ ภายในเวลาอันสั้น
  • Legacy code is code without tests

สิ่งที่ขอเน้นย้ำก็คือ ก่อนที่ใช้ทำอะไรสักอย่าง
ก็ขอให้ทำความเข้าใจกับแนวคิดด้านหลังมันหน่อย
เพื่อจะได้ไม่เข้าใจผิด ซึ่งถ้าเข้าใจผิดแล้ว จะทำให้นำไปใช้งานผิดอีกด้วย

ต่อจากนั้นทำการแนะนำโครงสร้างของ test

โดยมีโครงสร้างพื้นฐานดังรูป

Screen Shot 2557-08-21 at 9.18.04 PM

ส่วนรูปแบบที่ผมแนะนำก็คือ AAA ( Arrange, Act, Assert ) มีตัวอย่าง code ดังนี้

Screen Shot 2557-08-21 at 9.18.53 PM

เมื่ออธิบายทุกๆ อย่างแล้ว เราก็เข้าสู่กิจกรรม Coding Dojo

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

สุดท้ายแนะนำ กฏ 4 ข้อของ Simple Design ประกอบไปด้วย

  • All the tests pass
  • No duplication
  • Focus
  • Class and method are minimized

ขอขอบคุณงาน Thailand Practical Software Engineering ที่ให้โอกาสผมได้แบ่งปันเรื่องนี้ครับ

Slide ที่ผมพูดอยู่ที่นี่ครับ