สรุปบทความเรื่อง Write tests. Not too many. Mostly integration

ช่วงหลัง ๆ เรามักจะได้ยินรูปแบบการทดสอบระบบงานมากมาย ทั้ง ice cream testing, pyramid testing, cup cake testing รวมทั้งอีกหนึ่งแนวคิดคือ Trophy testing ซึ่งจะเน้นไปที่ทดสอบเฉพาะในส่วนที่จำเป็นมาก ๆ นั่นก็คือ Integration testing เป็นแนวคิดที่น่าสนใจมาก ๆ ก็เลยไปค้นหาข้อมูลเพิ่ม เลยเจอบทความเริ่มต้นคือ Write tests. Not too many. Mostly integration ทำการอธิบายได้ชัดเจน เลยนำมาแปลและสรุปไว้นิดหน่อย มาเริ่มกันเลย โดย blog นี้เป็นการสรุปสิ่งที่คุณ Kent C. Dodds พูดไว้ https://www.youtube.com/watch?v=Fha2bVoC8SE&list=PLV5CVI1eNcJgNqzNwcs4UKrlJdhfDjshf#action=share รวมทั้งคุณ 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 ขึ้นมา https://twitter.com/kentcdodds/status/960723172591992832?lang=en แน่นอนว่า แนวคิดนี้ก็มีข้อขัดแย้งกับ 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/