อ่าน research paper ของ Microsoft เรื่อง RESTler: Stateful REST API Fuzzingเป็นเครื่องมือสำหรับการทดสอบ REST API แบบ Fuzz testing หรือ Fuzzingคือรูปแบบหนึ่งของการทดสอบแบบ blackboxโดยจะพยายามหา bug หรือ ข้อผิดพลาดจาก input ในรูปแบบต่าง ๆ อย่างอัตโนมัติ
ในการพัฒนาระบบงาน มักจะมีการใช้งาน service อื่น ๆผ่าน HTTP protocol ด้วยเสมอเราจะเรียก service เหล่านั้นว่า dependency บ่อยครั้งที่การ integration test มักจะมีปัญหาดังนั้นจึงต้องทำการจำลอง service เหล่านั้นขึ้นมาเพื่อให้เราสามารถพัฒนาและทดสอบไปได้อย่างราบรื่นหนึ่งในเครื่องมือที่น่าสนใจและลองใช้งานหน่อยคือ Smocker
Selenium Grid 4 ใช้ W3C WebDriver protocol จากเดิมที่ยังใช้งาน JSONWire protocol ไปและยังได้เพิ่มเรื่องของการสนับสนุน DevTools protocol อีกด้วยแต่ยังอยู่ในช่วงของ experiment feature เท่านั้น
สิ่งที่น่าสนใจในการพัฒนาและส่งมอบให้เร็วพร้อมกับคุณภาพที่สูงนั้นเป็นคำถามที่น่าสนใจมาก ๆแน่นอนว่า เราอาจจะพบเจอปัญหาต่าง ๆ มากมายไม่ว่าจะเป็นปัญหาคอขวดในการทำงานไม่ว่าจะเป็นข้อจำกัดต่าง ๆ ของขั้นตอนการทำงานเราควรต้องทำอย่างไรดี ? สิ่งที่ควรจะทำคือ การปรับปรุงสิ่งพื้นฐานต่าง ๆ เหล่านี้แบบค่อยเป็นค่อยไปอย่างต่อเนื่อง
วันนี้อ่านบทความ Cypress vs Selenium vs Playwright vs Puppeteer speed comparisonทำการเปรียบเทียบความเร็วของการทดสอบของเครื่องมือแต่ละตัวประกอบไปด้วย Cypress Selenium Playwright Puppeteer เป็นเครื่องมือสำหรับการทดสอบแบบ End-to-End ผ่าน web browser
Mock Service Worker คือ library สำหรับการจำลองงาน ฝั่ง backend ที่ทางฝั่ง frontend เรียกใช้งานพัฒนาด้วยภาษา JavaScriptสามารถจำลองได้ทั้ง REST API และ GraphQL API Library ตัวนี้จะใช้งาน Service Worker API ใน modern web browserโดยทำการ intercept หรือดักจับ request ต่าง ๆ ที่ออกจาก browser นั่นเอง
จากที่ได้แนะนำเรื่องการพัฒนาและทดสอบระบบงานพวก RESTFul API ไปนั้น มีคำถามที่น่าสนใจเกี่ยวกับการทดสอบว่า เราจะทำการทดสอบอย่างไรดี ? จะทดสอบใน level ไหนบ้างเช่น integration, unit และ component เป็นต้น จึงสรุปคำแนะนำออกมาเป็นข้อ ๆ แบบสั้น ๆ ดังนี้
ปกติเขียน test ในภาษาโปรแกรมบน JVM ก็มี library/framework ให้เลือกเยอะ ทั้ง JUnit, Spock, Spek, Kotlin test แต่มีอีกตัวที่น่าสนใจคือ Kotest (ก่อนหน้านี้จะใช้ชื่อว่า KotlinTest แต่ไปซ้ำกับ test ที่มากับภาษา Kotlin จึงเปลี่ยนชื่อ) โดยมีความสามารถที่น่าสนใจมาก ๆ รวมทั้งเขียนง่ายด้วย ดังนั้นมาลองทำความรู้จักกันหน่อย
พอดีเพิ่งคุยเรื่องการเขียน test ที่เป็นทำงานแบบอัตโนมัติ จะเน้นที่การเขียน test code และ production code ไปด้วยกัน มีคำถามที่น่าสนใจคือ เหตุผลที่บอกว่าจะไม่เขียน test มันมีเยอะจนทำการสรุปได้ดังนี้ มาดูกันว่ามีเหตุผลอะไรบ้าง
ปัญหาที่เจอบ่อยมาก ๆ สำหรับการทดสอบแบบ End-to-End ยิ่งทดสอบผ่าน User Interface หรือ ระบบที่ต้องทำงานผ่านระบบ network คือ ทดสอบผ่านบ้าง ไม่ผ่านบ้าง โดยที่ code ไม่เปลี่ยนแปลงใด ๆ เลย !!ปัญหานี้จะถูกเรียกว่า Flakiness testing
