สิ่งที่น่าสนใจในการพัฒนาและส่งมอบให้เร็วพร้อมกับคุณภาพที่สูงนั้นเป็นคำถามที่น่าสนใจมาก ๆแน่นอนว่า เราอาจจะพบเจอปัญหาต่าง ๆ มากมายไม่ว่าจะเป็นปัญหาคอขวดในการทำงานไม่ว่าจะเป็นข้อจำกัดต่าง ๆ ของขั้นตอนการทำงานเราควรต้องทำอย่างไรดี ? สิ่งที่ควรจะทำคือ การปรับปรุงสิ่งพื้นฐานต่าง ๆ เหล่านี้แบบค่อยเป็นค่อยไปอย่างต่อเนื่อง
วันนี้อ่านบทความ 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
มาทำความรู้จักกับ Gauge เป็น test automation framework สำหรับการเขียน acceptance test ขึ้นมาในรูปแบบของ Markdown ช่วยทำให้สามารถเขียนชุดการทดสอบในรูปแบบเอกสารสาร (Documentation) ตอบโจทย์เรื่องของ Living documentation อย่างมาก น่าจะเป็นอีกทางเลือกหนึ่งที่น่าสนใจ มาเริ่มกันเลย
มีคำถามเกี่ยวกับการสร้าง repositry สำหรับจัดเก็บชุดการทดสอบ (Automated testing) ว่าควรทำอย่างไรดี ซึ่งปัจจุบันนั้นมักจะสร้าง repository แยกออกไปจาก source code ของทีมพัฒนา ด้วยเหตุผลเรื่องความเป็นเจ้าของและง่ายต่อการดูแล คิดว่ามีปัญหาหรือไม่
อ่านบทความเรื่อง Test Desiderata ของคุณ Kent Beck ซึ่งบทความนี้แปลง่าย ๆ คือ คุณสมบัติที่จำเป็นของ test นั่นเอง โดยทำการสรุปไว้ 12 เรื่อง จึงทำการแปลและสรุปตามความเข้าใจไว้นิดหน่อย
