ในทุกวันนี้การเขียนพวก unit test/integration หรือแม้แต่ acceptance test ล้วนแล้วแต่มีประโยชน์ รวมทั้งสามารถทำงานได้อย่างอัตโนมัติ หรือว่าทำงานด้วยคำสั่งเพียงบรรทัดเดียว แต่คุณเคยเข้าไปดูไหมว่าชุดของ test หรือ ชุดการทดสอบนั้น มันมีคุณภาพที่ดี สุขภาพที่ดี หรือไม่ ? มันมีประโยชน์สำหรับการพัฒนาระบบหรือไม่
ในการเขียน Unit test นั้น มันจะมีประโยชน์ และ มีประสิทธิภาพ สำหรับทีมพัฒนา แต่ unit test จำเป็นต้องมีคุณสมบัติ FIRST ดังนี้ Fast Isolated Repeatable Self-verify Timely มาดูกันว่าแต่ละหัวข้อนั้นคืออะไร และเป็นอย่างไร ? แล้วลองมองย้อนกลับไปว่า Unit test ที่เขียนหรือสร้างกันขึ้นมานั้น มันมีคุณสมบัติต่างๆ เหล่านี้ครบหรือไม่
คำถามที่คุณอาจจะถามตัวเอง ซึ่งผมก็เคยถามและตอบตัวเองไปแล้ว ดังนี้ คำถาม ถ้าเราทำ integration และ system test ไปแล้ว ทำไมจะต้องทำ unit test ด้วยล่ะ ? คำตอบก็คือ มันเรียบง่ายไงล่ะ &#
หลังจากที่รู้แล้วว่า โครงสร้างที่ดีของ unit test เป็นอย่างไร ต่อมาขอแนะนำวิธีการทำให้ unit test ดูดีขึ้นไปอีก นั่นก็คือ การเป็นอิสระจาก code ที่เราพัฒนาจริงๆ เพื่อให้การทดสอบมีความคล่องตัว เป็นอิสระต่อส่วนต่างๆ ที่ต้องเกี่ยวข้อง เช่น Database, Network และระบบไฟล์ เป็นต้น แล้วมันทำอย่างไรล่ะ
JUnit เป็น library สำหรับการเขียน unit test สำหรับภาษา Java ซึ่งหลายๆ คนบอกว่า มันอาจจะดูน่าเบื่อ ไม่ได้ต้องไปสนใจอะไรมากนัก แต่ถ้าเขียน หรือ ใช้มันแบบไม่สนใจอะไร จะพบว่า unit test ที่เขียนขึ้นมานั่นแหละ มันจะทำให้คุณลำบาก เช่น ดูแลรักษายาก แก้ไขยาก แก้ code ครั้งหนึ่งกระทบ test เยอะไปหมดเลย ใช้เวลาในการพัฒนาสูง ไม่ไว้ในการทดสอบ ดังนั้นมาดูว่า จะเขียน unit test ด้วย JUnit อย่างไรให้ดูดีมีสาระ
ในการพัฒนา software ในปัจจุบันในบ้านเรา เริ่มมีการพูดถึง unit test เยอะขึ้น แต่สิ่งหนึ่งที่มักได้ยินจาก developer ที่ไม่เขียน ก็คือ มันเขียนยาก นั่นคือเหตุผลหลัก ที่ทำให้ไม่เขียน unit test หรือจะพยายามบอกว่า ไม่มีเวลา มันใกล้ dead line แล้ว หรือบอกว่า ถ้าทำ unit test แล้วต้องให้มันครอบคลุม code ใกล้ 100% จากเหตุผลเหล่านี้ ทำให้การพัฒนา software พาเราเข้าสู่โลกมืด (Dark side) ซึ่งมันง่ายที่จะเข้าไป แต่ยากที่จะถอนตัวออกมา &#
ในการพัฒนา software นั้นสิ่งหนึ่งที่มันมีค่ามากๆ นั่นก็คือ Feedback ไม่ว่า feedback นั้นจะอยู่ในรูปแบบใดๆ ก็ตาม มันมีค่าเสมอ เพราะว่า มันช่วยนำทางเราไปให้ถึงจุดหมายที่ตั้งหรือคาดหมายไว้ ซึ่งในแนวปฏิบัติต่างๆ สำหรับการพัฒนา software มีเป้าหมายเพื่อ feedback ล้วนๆ ถึงจะมีชื่อ หรือ รูปแบบที่แตกต่างกัน ตัวอย่างเช่น Test-Driven Development (TDD) Continuous Integration (CI) Standup meeting Iteration
ผมเชื่อว่า หลายๆ คนที่เขียน unit test นั้น มักจะมีการจัดการ unit test ในรูปแบบดังนี้ ถ้าทำการทดสอบคลาส User จะสร้าง unit test ชื่อว่า UserTest ขึ้นมา และใน UserTest จะประกอบไปด้วย test case หรือ test method จำนวนมากมาย ซึ่งพบว่า เราก็จะทำการเพิ่ม test case เข้าไปเรื่อยๆ ตามจำนวนของ requirement หรือ feature หรือตามเงื่อนไขต่างๆ ที่เพิ่มเข้ามา สุดท้าย พบว่า มันใหญ่มากๆ แล้วเราแก้ไขอย่างไรกันล่ะ
ช่วงหลังๆ มีโอกาสแลกเปลี่ยนความเห็นเกี่ยวกับเรื่อง Test Coverage หรือ Code Coverage อยู่บ่อยครั้ง เรื่องหนึ่งที่น่าสนใจก็คือ ให้ความสนใจกับระดับของ Test Coverage สูงๆ เป็นหลัก เพราะว่า คิดว่า ถ้าระดับมันสูงแล้ว code ที่เขียนขึ้นมาต้องมีคุณภาพที่ดี และ bug ต่างๆ จะน้อยลงอย่างแน่นอน ซึ่งผมคิดว่า มันเป็นเรื่องที่ไม่น่าจะถูกต้องมากนัก สำหรับการสนใจเพียงระดับของ Test Coverage ที่สูงๆ เพียงอย่างเดียว โดยไม่สนใจเรื่องคุณภาพของ Test ที่เขียนขึ้นมา
เห็นเอกสารและวิธีการสอนเกี่ยวกับ Testing 101 สำหรับทีมพัฒนาของ Esty.com แล้วชอบมากๆ เลยเอามาสรุปนิดหน่อย ว่าที่นี่ทำกันอย่างไร มีเนื้อหาการสอนอะไรบ้าง รวมทั้งเอกสารต่างๆ ที่ใช้งาน ที่สำคัญข้อมูลทั้งหมดเราสามารถนำมาใช้ฝึกฝนได้เลยครับ มาดูกันเลยดีว่า วัฒนธรรมของทีมเป็นอย่างไร