ช่วงหลัง ๆ เรามักจะได้ยินรูปแบบการทดสอบระบบงานมากมาย
ทั้ง 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 ขึ้นมา
"The Testing Trophy" ?
A general guide for the **return on investment** ? of the different forms of testing with regards to testing JavaScript applications.
– End to end w/ @Cypress_io ⚫️
– Integration & Unit w/ @fbjest ?
– Static w/ @flowtype ? and @geteslint ⬣ pic.twitter.com/kPBC6yVxSA— Kent C. Dodds (@kentcdodds) February 6, 2018
แน่นอนว่า แนวคิดนี้ก็มีข้อขัดแย้งกับ 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/