เจอ VDO จากงาน London Gophers Meetup
ซึ่งมีหัวข้อน่าสนใจดังนี้
- Warning data race exit status 66
- Go three months in
- Absolute Unit (Test)
- Decoding binary network protocol
สามารถดู VDO ของหัวข้อต่างได้ที่ Youtube
แต่หัวข้อที่จะทำการสรุปคือ Absolute Unit (Test) พูดโดยคุณ Dave Cheney
มีหลายเรื่องที่น่าสนใจ
มาเริ่มกัน
เริ่มจาก TDD (Test Driven Development) คืออะไร ?
ก็ไปค้นจาก google เอานะ แล้วจะเจอแบบนี้ !!!
มีพูดถึงผู้สร้างแนวคิด TDD และกฎ 3 ข้อของ TDD
แต่เรื่องที่สำคัญคือ แนวทาง TDD ของคุณ Dave Cheney ที่มีต่อภาษา Go
นั่นคือ
ถ้ารู้ว่าจะเขียนอะไร จะเริ่มที่เขียน test ให้ fail ก่อนเสมอ
แต่ถ้าไม่รู้ว่าจะเขียนอะไร ค่าใช้จ่ายสำหรับการลองหรือทดลองมันจะเริ่มที่ 200%
เพราะว่าต้องเสียเวลาไปกับการแก้ไข code และแก้ไข test
ดังนั้นการเริ่มจากการไม่รู้เป้าหมายของสิ่งที่จะทำ
มันมีค่าใช้จ่ายสูงมาก ๆ ระวังกันไว้ด้วยละ
การเขียน test ที่ครอบคลุม มันทำให้เรามั่นใจเมื่อมีการเปลี่ยนแปลง
แต่การไปแก้ไข test มันเหมือนการโกง !!
รวมทั้งนักพัฒนาอย่างเรา ๆ ไม่น่าจะมีความสุข
ถ้า test มีจำนวนน้อย ๆ ใช่ไหม
หรือเพราะว่างานมันเร่ง เลยต้องทิ้งทุกอย่างไป
สิ่งที่เรากำลังทดสอบนั่นคือ SUT (System Under Test)
นั่นหมายความว่ามันไม่ใช่ class หรือ ไฟล์ใดไฟล์หนึ่ง
แต่มันคือระบบทั้งระบบ
อธิบายว่า
Go package นั้นมีแนวคิดมาจาก UNIX philosophy
คือการที่แต่ละ package จะติดต่อกันผ่าน interface เสมอ
ทำให้ program หรือระบบงานคือ การนำ package ต่าง ๆ มารวมกันเพื่อทำงานด้วยกัน
แน่นอนว่า แต่ละ package จะไม่ผูกมัดไปที่ implementation
แต่จะสนใจไปที่พฤติกรรมหรือ behavior ของการทำงานมากกว่า
ซึ่งนี่คือที่มาว่า
The unit of software in Go is the package
โดยที่ public API ของแต่ละ package นั้น
จะประกาศว่าทำอะไรได้บ้าง (What) นั่นคือพฤติกรรมนั่นเอง
แต่จะไม่บอกว่าทำงานอย่างไร (How) หรือ implementation
ส่งผลให้ถ้าแต่ละ package ทำการเปลี่ยน implmentation แล้ว
จะไม่กระทบต่อการใช้งานเลย
เป็นอีกหนึ่ง feature ของภาษา Go
ส่วน Code coverage คือ guide นำทาง
ว่า code ส่วนไหนถูกทดสอบหรือไม่
ถ้าไม่ทดสอบน่าจะลบทิ้งไป
เนื่องจากไม่ถูกใช้งาน
รวมทั้งช่วยให้เรารู้ว่าส่วนไหนที่ต้องเพิ่ม test เข้าไป
แต่ถ้าค่า Code coverage สูง แนะนำให้เพิ่ม fuzzy testing เข้ามา
เพื่อช่วยตรวจสอบว่า edge case มันครอบคลุมหรือไม่
มี Guideline ให้ด้วย (Not Rules)
- ควรเขียน test
- ควรเขียน test ไปพร้อม ๆ กับการเขียน production code
- แต่ละ Go package คือ unit ของการทำงาน
- Test หรือชุดการทดสอบ ควรตรวจสอบพฤติกรรมการทำงานของ package ไม่ใช่ไปตรวจสอบ implementation
- การออกแบบ package นั้นควรเริ่มว่า package นั้นมีพฤติกรรมการทำงานอะไรบ้าง ไม่ใช่ลงไปว่าทำอย่างไร
สามารถ Download Slide ของ VDO เรื่องนี้ได้เลย