อยากจะเริ่มทำ TDD เริ่มยังไงดี

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

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

คำถามแรกที่ต้องตอบเลยคือ “งานของเรามันจะเสร็จได้ยังไง?”

ผมเคยอ่านบทความอันนึงเป็นของคนที่ไปเรียนกับ Kent Beck มา แกบอกว่า ก่อนอื่นให้ตั้งเป้าหมายก่อนว่า เย็นนี้เราจะ demo อะไร แล้วมี test อะไรที่ต้องเขียนบ้าง

ก็ลองนึกดูนะครับ ว่างานที่คุณกำลังจะทำเนี่ย มันจะทดสอบยังไง อะไรถูก อะไรผิด input คืออะไร output คืออะไร ผลลัพธ์ที่ต้องการหน้าตามันเป็นอย่างไร ยิ่งถ้ารู้ว่าทำไปทำไมด้วยเนี่ย จะยิ่งประเสริฐมากๆครับ

แล้วถ้านึกไงก็นึกไม่ออกล่ะ ทำไง

มันก็แปลว่า เรายังไม่เข้าใจปัญหาที่เรากำลังแก้เพียงพอนะครับ อันนี้แนะนำให้คุย ครับ คุยเข้าไป การสื่อสารเท่านั้นที่จะช่วยได้ คุยกับทีม, คุยกับ tester, คุยกับ product owner, คุยกับลูกค้า ฯลฯ แต่ไปคุยแล้วห้ามกลับมามือเปล่านะครับ ต้องได้ test case ที่ตกลงร่วมกันกับคนที่ไปคุยด้วยกลับมา ถ้าไม่ได้อะไรกลับมา มันก็แปลว่าเรากำลังทำงานอยู่บนความเสี่ยง ที่สูงมากๆ มีโอกาสสูงมากที่มันจะไม่ได้นำไปใช้ หรือไม่ก็ต้องกลับมาแก้ไขมันอยู่เรื่อยๆ ไม่จบสิ้นสักที (ฝรั่งเขาเรียกว่า Boomerang job ครับ ขว้างไปยิ่งแรงยิ่งกลับมาเร็ว :p )

ถ้าเป็นคนคุยไม่เก่งทำไง ก็ต้องฝึกนะครับ! ไม่แน่ว่าคนที่คุณไม่กล้าคุยเค้าอาจจะรอคุณอยู่ก็เป็นได้

ลองมาดูตัวอย่างกัน เทคนิคมันก็มีหลากหลายแล้วแต่สถานการณ์ แต่ผมชอบที่จะสรุปมันออกมาเป็นตารางมากกว่า สมมติว่าเป็นหน้าล็อกอิน(คลาสสิคมากกก)

ลองดูดีๆ มันแบ่งออกมาเป็น Login สำเร็จ กับไม่สำเร็จได้ไหมนะ

โอเค วันนี้อย่างน้อย เราจะเดโม ฟีเจอร์ “Login สำเร็จ”

แล้ว Login สำเร็จมันต้องทำอะไรบ้างล่ะ

ก่อนอื่นเลยต้องทำความเข้าใจโครงสร้างของระบบงานของเราก่อนนะครับ ยกตัวอย่าง Web application ที่นิยมกันมันก็น่าจะมีประมาณนี้ ถ้ายังวาดภาพออกมาแบบนี้ไม่ได้ก็แปลว่าเรายังไม่ได้เข้าใจระบบเราเท่าไหร่ครับ แนะนำให้กลับไปทำความเข้าใจให้ดีก่อน

ต่อมาถ้าเราจะลงมือเขียนโค้ดจริงๆล่ะ เราต้องทำยังไงบ้างลองเอามาตีแผ่ดูครับ เริ่มจากวิธีการทำงานแบบเดิมๆของเราเนี่ยแหละ

พอจะปรับให้มาเป็น TDD นั้น เริ่มแรกสุดก็ต้องนำแนวคิด Acceptance Test Driven Development(ATDD) เข้ามาใช้ เริ่มจากเขียน Automated acceptance test หรือ UI automated test นั่นเอง เราจะได้มีเครื่องมือทดสอบที่ครอบคลุมการทำงานของฟีเจอร์ “Login สำเร็จ” นะครับ

ต่อมาก็ Automated test สำหรับ REST API บางคนอาจจะสงสัยว่า ต้องเขียนด้วยเหรอ? ตอนแรกผมก้คิดว่ามันไม่สำคัญนะครับ แต่พอเวลาผ่านไป API ของเรามีมากขึ้นๆ เราก็เริ่มจำไม่ได้แล้วว่า API แต่ละตัว มันต้องส่งข้อมูลหน้าตายังไง มันจะตอบอะไรกลับมา หรือการ login เนี่ย ขั้นตอนการ Authorize มันมีอะไรบ้าง เพราะฉะนั้น การเขียน test ที่ระดับนี้จึงมีความสำคัญเช่นเดียวกัน เป็นการบังคับให้เราต้องมาออกแบบการรับส่งข้อมูลก่อนที่จะไปลงมือเขียนโค้ดนะครับ

เครื่องไม้เครื่องมือก็มีหลากหลาย

เช่น

หรือเฉพาะทาง Mobile อย่าง

สำหรับ Automated API test

  • Robot framework requests library
  • REST-Assure สำหรับคนรัก Java

หรือลองหาเครื่องมือสำหรับทดสอบ REST api ในภาษาที่คุณหรือทีมของคุณถนัดกันนะครับ

ในระดับมีอีก Concept หนึ่งที่น่าสนใจ เขาเรียกกันว่า Living documentation ก็คือ ทำ Test ที่เราเขียนให้เป็น Document ของงานไปในตัว คนอ่านก็รู้เรื่อง เอาไปให้เครื่องคอมพิวเตอร์ Execute ก็ได้ ลองไปอ่านเพิ่มเติมกันครับ

อาจจะมีตัวอื่นๆอีกนะครับ รัก ชอบตัวไหน สนใจตัวไหนก็ลองศึกษากันดู ไม่เสียเปล่าแน่นอนครับ ที่สำคัญคือต้อง ฝึก ฝึก ฝึก และ ฝึก อีกแล้วครับ

ในส่วนต่อมาก็คือการเข้าสู่กระบวนการ TDD จริงๆละ ก็คือการที่เราเขียน Unit test ควบคู่ไปกับการเขียนโค้ดนะครับ จุดแรกที่เราจะลงไปทำ คือโค้ด Javascript ที่ทำหน้าที่ในการส่งข้อมูล username, password และรับผลกลับมา

ตรงนี้ก็ไปดูเครื่องมือสำหรับการทำ unit test ในภาษาหรือเครื่องมือที่ใช้กันนะครับ สำหรับ Javascript ลองศึกษาดูสองตัวนี้

  • karma
  • jasmine

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

ลำดับสุดท้ายก็คือเขียน Unit test สำหรับโค้ดของ API

เครื่องมือสำหรับทำ Unit test จริงๆแล้วมันก็มีทุกภาษาแหละครับ ลองไปหาดูกันนะ ถ้าเป็น Java ก็ JUnit หรือ NG-test

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

จะเห็นว่า เฮ้ย! นี่งานมันเพิ่มขึ้นบานเลยนี่

คำตอบคือ ใช่ครับ

แต่ผมขอถามย้ำอีกทีว่า

  • คุณแน่ใจได้อย่างไรว่างานที่คุณทำน่ะมันเสร็จแล้ว
  • คุณมั่นใจโค้ดที่คุณเขียนแค่ไหน
  • เราจะทำอย่างไรให้ไม่ผิดที่เดิมซ้ำๆซากๆ
  • จะแนใจได้อย่างไรว่าโค้ดใหม่ที่เพิ่มเข้าไปมันไม่ได้ทำให้ของเดิมที่ทำงานได้อยู่มันพัง

ก่อนจบผมจะขอทวนอีกครั้งครับ นี่คือสิ่งที่ต้องทำความเข้าใจหากอยากจะเริ่มทำ TDD

  • เข้าใจตัว Product
  • เข้าใจโครงสร้างของระบบ
  • เข้าใจปัญหาที่กำลังจะแก้ หรือ Feature ที่กำลังจะทำ
  • เข้าใจและออกแบบการทดสอบสำหรับปัญหาที่กำลังจะแก้
  • เข้าใจ ATDD
  • เข้าใจ TDD

จะเข้าใจทั้งหมดนี้ได้ มีทางเดียวครับ นั่นคือ ฝึก ฝึก ฝึก และ ฝึก!

แถมๆๆ แนะนำหนังสือที่ควรไปอ่านถ้าอยากเริ่มทำ TDD

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.