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

มีคนถ่ายรูปไว้ให้ด้วย ขอบคุณมากๆ ครับ
[fb_embed_post href=”https://www.facebook.com/somkiatspns/posts/10152666379593588/” width=”550″/]

เริ่มต้นด้วยการนำ 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 ที่ผมพูดอยู่ที่นี่ครับ