ช่วงหลัง ๆ เรามักจะได้ยินรูปแบบการทดสอบระบบงานมากมาย
ทั้ง ice cream testing, pyramid testing, cup cake testing
รวมทั้งอีกหนึ่งแนวคิดคือ Trophy testing
ซึ่งจะเน้นไปที่ทดสอบเฉพาะในส่วนที่จำเป็นมาก ๆ นั่นก็คือ Integration testing

เป็นแนวคิดที่น่าสนใจมาก ๆ ก็เลยไปค้นหาข้อมูลเพิ่ม
เลยเจอบทความเริ่มต้นคือ Write tests. Not too many. Mostly integration
ทำการอธิบายได้ชัดเจน เลยนำมาแปลและสรุปไว้นิดหน่อย
มาเริ่มกันเลย

โดย blog นี้เป็นการสรุปสิ่งที่คุณ Kent C. Dodds พูดไว้

รวมทั้งคุณ Guillermo Rauch ผู้สร้าง Socket.io ได้ tweet ไว้ว่า

Write tests. Not too many. Mostly integration.
https://twitter.com/rauchg/status/807626710350839808

จาก tweet นี้สามารถลงรายละเอียดไปได้ 3 ส่วนคือ

ส่วนที่ 1 คือ Write tests

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

ในการสร้าง automated test นั้นอาจจะใช้เวลานานหรือไม่นานก็แล้วแต่
แต่สิ่งหนึ่งที่ได้กลับมาคือ ลดเวลาในการดูแลรักษาระบบนั่นเอง

สิ่งที่ควรคำนึงในการเขียน automated test คือ
คุณมีความมั่นใจมากน้อยเพียงใด
ที่มันจะช่วยทำให้ระบบงานเราไม่มีข้อผิดพลาด

เช่นการใช้งาน static typing และ lint น่าจะช่วยให้เรามีความมั่นใจมากยิ่งขึ้น
ว่า code ที่เราเขียนขึ้นมาถูกต้องตามมาตรฐาน
แต่ไม่ได้บอกว่า business logic จะทำงานได้อย่างถูกต้อง ไร้ข้อผิดพลาด
ดังนั้นเราต้องเพิ่มความเชื่อมั่นด้วยการเขียน automated test ที่ดี ๆ เข้ามาเพิ่มนั่นเอง

ส่วนที่ 2 คือ Not too many

ไม่เขียน automated test มากจนเกินไป
หลาย ๆ องค์กรเมื่อได้ยินเรื่องของ code coverage แล้ว
ทาง manager และ team มักจะชอบตั้งเป้าหมายให้ค่า coverage สูง ๆ เช่น 100%
ดังนั้นเมื่อค่า code coverage ลดลง สิ่งที่นักพัฒนาต้องทำคือ
เขียน automated test เพิ่มเติมเพื่อให้ code coverage เพิ่มขึ้น
สิ่งเหล่านี้คือ ปัญหา เนื่องจากเราจะเสียเวลามากมายไปกับการเขียน automated test
ส่วนใหญ่จะไม่จำเป็นต้องทดสอบ
ที่สำคัญการดูแล automated test แบบนี้จะทำให้เราและทีมช้าลงอย่างมาก

รวมทั้งถ้าเราทดสอบในรายละเอียดมากจนเกินไป
สิ่งที่ตามมาคือ เมื่อมีการเปลี่ยนแปลง code แล้ว
จะกระทบต่อ automated test จำนวนมาก
ซึ่งเป็นสิ่งที่ไม่ดีเลย

แต่ถ้าสำหรับ open source project มักจะมีค่า code coverage 100%
เพราะว่า project มีขนาดเล็ก และเป็นเครื่องมือที่ถูกนำไปใช้ในหลายกรณี
ดังนั้นเรื่อง breaking change จึงเป็นสิ่งที่สำคัญมาก ๆ ต้องระมัดระวังด้วยการเขียน automated test ที่ครอบคลุม

ส่วนที่ 3 คือ Mostly integration

การทดสอบนั้นมีหลายชนิดมาก ๆ แล้วแต่แหล่งที่มากันเลย
ยกตัวอย่าเช่น Unit, Integration และ End-to-End testing
โดยแต่ละชนิดก็มีทั้งข้อดีและข้อเสีย

ในบทความจะยกตัวอย่างจาก slide เรื่อง Testing JavaScript Application

จากรูปนั้นคือ Test Pyramid
โดยเวลาและ resource ที่ต้องใช้สำหรับการเขียน ทดสอบ และดูแลรักษา automated test
จะมากขึ้นจากล่างขึ้นบนคือ Unit > Integration > End-to-End
นั่นหมายความว่า ให้เน้นในส่วนของ Unit test มาก ๆ
แต่สิ่งหนึ่งที่ไม่ได้แสดงใน Test Pyramid คือ ความเชื่อมั่น
ซึ่ง End-to-End test นั้นสร้างและทดสอบก็ช้า ใช้ resource เยอะ
แต่เรื่องของความเชื่อมันในการทดสอบก็สูงด้วย

ดังนั้นผู้เขียนบทความจึงเน้นไปที่เรื่องของความเชื่อมั่นของการทดสอบ
จึงได้คิด The Test Trophy ขึ้นมา

แน่นอนว่า แนวคิดนี้ก็มีข้อขัดแย้งกับ Unit test
แสดงดังรูป

โดย Unit test ก็คือการทดสอบในแต่ละส่วน ซึ่งทำงานถูกตามที่ต้องการ
แต่ไม่ได้หมายความว่า รวมกันแล้วจะทำงานได้ถูก
ดังนั้นสิ่งที้่ขาดไม่ได้คือ แต่ละส่วนงานต้องทำงานด้วยกันได้
นั่นคือ Integration test นั่นเอง
สิ่งที่ต้องคิดเพิ่มคือ ในการเขียน automated test นั้น
ต้องคิดถึงทั้งความเชื่อมั่น ความเร็วและค่าใช้จ่ายที่ลงไป
ว่ามันคุ้มไหม ?

 

How to write more integration tests ?

เส้นแบ่งระหว่าง unit และ integration test นั้นอาจจะทำให้สับสนได้
แต่สิ่งที่สำคัญมาก ๆ สำหรับการเขียน integration test คือ
หยุดการใช้ mock หรือลดการใช้ mock ให้น้อยที่สุด ใช้เท่าที่จำเป็น
เพราะว่า การใช้ mock คือการลดความเชื่อมั่นของ integration test นั่นเอง
เพราะว่า มันไม่ใช่ของจริง
แต่บางครั้งอาจจะต้องใช้การ mock
เช่นไม่จำเป็นต้องส่ง email และตัดเงินผ่านบัตรเครดิตเป็นต้น

Reference Websites
https://blog.kentcdodds.com/write-tests-not-too-many-mostly-integration-5e8c7fff591c
https://frontendmasters.com/courses/testing-react/testing-trophy/

Tags:,,,