แนวการทดสอบ React components จาก React Testing Recipes: chapter 3
มาถึงกันในบทสุดท้ายของ React Testing Recipes ก่อนอื่นขอบคุณ document ที่ได้จาก https://reactjs.org/docs/testing-recipes.html
สำหรับตอนก่อนหน้า
- แนวการทดสอบ React components จาก React Testing Recipes: chapter 1
- แนวการทดสอบ React components จาก React Testing Recipes: chapter 2
Snapshot Testing
เฟรมเวิร์กอย่าง Jest สามารถทำการ “snapshot” ด้วยฟังก์ชัน toMatchSnapshot / toMatchInlineSnapshot ทำให้เราบันทึกการ render ของ component output และทำให้มั่นใจได้ว่าเราจะถูกครั้งที่เราแก้ไขโค้ดมันจะไม่ไปกระทบการ render ของ component ที่ไม่เกี่ยวข้อง
ตัวอย่างจะเป็นการ render component และฟอแมตซ์ผลลัพธ์ออกมาเป็น HTML ด้วย package ที่ชื่อว่า pretty แล้วค่อย save ออกมาเป็น inline snapshot
โดยหลักการแล้วมันดีกว่าที่จะใช้ assertion แบบระบุไปตรง ๆ เลย ดีกว่าจะใช้ snapshot เพรราะ test ประเภท snapshot มันจะเช็คถึงระดับ implementation details ทำให้โอกาสที่ test พังง่ายกกว่า และทีม can get desensitized to snapshot breakages การเลือกที่จะ mock ค่า child component บางตัว ก็ช่วยให้เราลดขนาดของ snapshot file และทำให้มันอ่านง่ายด้วย
ในมุมมองของผม ผมมักจะเขียน snapshot test น้อย ๆ ใช้กับ component ส่วนที่มีโอกาสเปลี่ยนแบบนาน ๆ ที และต้องการ strict ในผลลัพธ์ในมุมมองคือพวก core component ส่วนเล็ก ๆ ที่มาจาก design system เช่น button, label เป็นต้น
Multiple Renderers
บางครั้งเราอาจจำเป็นต้อง test component ที่ใช้ multiple renderers แต่กรณีนี้แทบไม่ค่อยเห็น
ตัวอย่างของการทำ multiple renderers เช่นเรารัน snapshot test กับ component ตัวนึง โดยใช้ react-test-renderer ที่ภายในมีการใช้งาน ReactDOM.render ด้านใน child component เพื่อ render เนื้อหา ซึ่งกรณีนี้เราอาจจะต้องใช้ฟังก์ชัน act เพื่อให้มั่นใจว่าผลลัพธ์ที่ได้จากการ render ของ component render ทำการอัปเดตแล้ว โดยเราจะทำการครอบ 2 ชั้นแบบนี้
น่าจะพอให้เห็นภาพคร่าว ๆ ว่า react มีวิธีการทดสอบแบบไหนกันบ้าง ที่เหลือก็ต้องไปฝึกฝนต่อว่าส่วนไหนต้อง test แบบไหนกันละครับ หรือใครอยากต่อยอดก็สามารถศึกษา https://testing-library.com/docs/react-testing-library/intro/ ต่อได้ โดย library ก็จะเอา concept การ test ที่เราเล่ากันมาให้เขียนได้ง่ายขึ้น
อยากย้ำกับทุกคนว่าอย่าพึ่งไปคิดว่าเราจะต้องเขียน test เท่าไร test coverage กี่เปอร์เซ็นต์ แต่ต้องถามว่าเราเขียน test ไปทำไมก่อน
Special Thanks
ขอขอบคุณ “สำนักงานส่งเสริมเศรษฐกิจดิจิทัล (depa)” และคณาจารย์ “คณะเทคโนโลยีสารสนเทศ มจธ. (SIT)” ที่ให้การสนับสนุน “ทุนเพชรพระจอมเกล้าเพื่อพัฒนาเทคโนโลยีและนวัตกรรมดิจิทัล (KMUTT-depa)” ซึ่งเป็นทุนที่มอบความรู้ ทักษะและโอกาสดีในการฝึกฝนพัฒนาทักษะที่มีอยู่ให้เฉียบคมมากยิ่งขึ้นครับ ❤
