Playwright หรือ Cypress: ความเร็วไม่ได้ชนะทุกกรณีทดสอบ

Playwright และ Cypress ต่างกันทั้งวิธีรอหน้าเว็บ ขอบเขตเบราว์เซอร์ ภาษาที่ใช้เขียนเทสต์ และวิธีไล่หาสาเหตุเมื่อเทสต์ล้ม ทีมที่ต้องตรวจหลายเอนจินหรือดูแลชุดทดสอบด้วยภาษานอก JavaScript มีเหตุผลให้เริ่มพิจารณา Playwright ส่วนทีม JavaScript หรือ TypeScript ที่ให้ความสำคัญกับการเห็นลำดับคำสั่งขณะพัฒนาอาจเหมาะกับ Cypress มากกว่า ความเร็วของกรณีทดสอบหนึ่งกรณีตัดสินแทนความต้องการเหล่านี้ไม่ได้

ทั้งสองเครื่องมือรอองค์ประกอบที่ยังไม่พร้อมและตรวจผลซ้ำได้ แต่กติกาการรอต่างกัน จึงเขียนและแก้เทสต์ด้วยวิธีต่างกันด้วย คำตอบสำหรับทีมเว็บคือเลือกจาก flow ที่ต้องทดสอบจริง เบราว์เซอร์ที่ต้องรับรอง และทรัพยากรที่ใช้รันทั้งชุด โดยให้เวลาในการรันเป็นข้อมูลประกอบการตัดสินใจ ไม่ใช่คะแนนรวมเพียงตัวเดียว

ผลวัดความเร็วขึ้นกับงานที่ให้เครื่องมือทำ

งานทดลองของ Michał Moń และ Beata Pańczyk ใช้กรณีทดสอบเว็บร้านเครื่องมือสมมติ 10 กรณี รันกรณีละ 10 ครั้งบนเครื่อง Windows แล้วเฉลี่ยเวลารันกับสัดส่วนการใช้ CPU และ RAM; ตารางเวลาระบุว่า Playwright เร็วที่สุด 6 กรณี ขณะที่ Selenium เร็วที่สุดในอีก 4 กรณี และสัดส่วน RAM ที่วัดระหว่างรัน Cypress สูงที่สุดทุกกรณี ตัวเลข RAM เป็นสัดส่วนหน่วยความจำที่วัดบนเครื่องทดลองระหว่างการรัน ไม่ใช่ข้อกำหนด RAM ขั้นต่ำของ Cypress หรือค่าที่จะเกิดซ้ำบน CI ทุกเครื่อง

กรณีที่ Playwright ทำเวลาได้ดีมีงานสั้นอย่างการสมัครสมาชิก เข้าสู่ระบบ ส่งแบบฟอร์ม และเปิดหน้ารายงาน งานที่ต้องเปลี่ยนสถานะตะกร้าสินค้าเชื่อมหลายขั้นตอนให้ลำดับต่างออกไป: Cypress ใช้เวลาน้อยกว่า Playwright ในบางกรณี แม้ Selenium จะยังเร็วที่สุดในกรณีเหล่านั้น ดังนั้นคำว่าเครื่องมือใดเร็วกว่าใช้ได้ต่อเมื่อระบุ flow และคู่ที่นำมาเปรียบเทียบ

ชุดทดลองยังมีงานเปลี่ยนรหัสผ่าน ดาวน์โหลดใบแจ้งหนี้ และเพิ่มสินค้าเป็นรายการโปรด งานเหล่านี้ต่างจากการคลิกปุ่มครั้งเดียว เพราะต้องผ่านสถานะผู้ใช้ การนำทาง หรือผลตอบกลับของแอปหลายจุด หากชุดเทสต์ของทีมมีงานลักษณะนี้มาก เวลาเฉลี่ยของกรณีสมัครสมาชิกหรือเปิดหน้าหนึ่งหน้าอาจทำนายเวลาทั้ง pipeline ได้ไม่ดี

ผลบนเครื่องทดลองช่วยชี้ว่าควรแยกกรณีสั้นกับ flow ยาวเมื่อประเมินความเร็ว แต่ไม่ใช่ผลทดสอบบนเครื่อง CI ของผู้อ่านเอง การเปลี่ยนแอป ข้อมูลเริ่มต้น เบราว์เซอร์ จำนวนงานที่รันพร้อมกัน หรือความเร็วของบริการหลังบ้านล้วนเปลี่ยนเวลาที่สังเกตได้ การเปรียบเทียบที่ใช้ตัดสินใจจึงต้องรักษาเงื่อนไขเหล่านี้ให้เทียบกันได้

Auto-wait และ retry ทำให้เทสต์เสถียรคนละทาง

กติกา auto-wait ของ Playwright ระบุว่า ก่อนสั่งคลิก locator ต้องชี้ไปยังองค์ประกอบเดียวที่มองเห็น อยู่ในสภาพนิ่ง รับเหตุการณ์คลิกได้ และไม่ถูกปิดใช้งาน หากเงื่อนไขยังไม่ครบ เครื่องมือจะรอจนผ่านหรือหมดเวลา ส่วน assertion ที่รองรับจะตรวจซ้ำระหว่างรอผล วิธีนี้มีประโยชน์กับหน้าที่ปุ่มปรากฏแล้วแต่ยังเคลื่อนไหวอยู่ หรือมีองค์ประกอบอื่นบังตำแหน่งคลิก

Playwright ไม่ได้ใช้เงื่อนไขชุดเดียวกับทุก action การกรอกช่องข้อมูลต้องตรวจว่าองค์ประกอบมองเห็น เปิดใช้งาน และแก้ไขได้ ขณะที่การเลื่อนองค์ประกอบเข้ามาในหน้าจอใช้เงื่อนไขอีกแบบ ความต่างนี้มีผลเวลาแก้เทสต์: หากคลิกไม่ผ่าน คำถามแรกอาจเป็นเรื่องสิ่งที่บังปุ่ม แต่หากกรอกค่าไม่ได้ต้องดูว่าช่องนั้นพร้อมแก้ไขหรือยัง

กติกา retry ของ Cypress ให้ query ที่เชื่อมกันกับ assertion ลองใหม่เป็นสายจนเงื่อนไขผ่านหรือหมดเวลา ส่วนคำสั่งที่ไม่ใช่ query ทำงานครั้งเดียว Cypress ยังตรวจความพร้อมก่อน action อย่างการคลิก แล้วจึงพยายามทำ action นั้นครั้งเดียว จึงไม่ถูกต้องที่จะอธิบายว่า Cypress เพียงค้นหาองค์ประกอบซ้ำโดยไม่สนใจว่าคลิกได้หรือไม่

ผลต่างเห็นชัดเมื่อหน้าเว็บสร้างองค์ประกอบใหม่หลังรับข้อมูลจากเซิร์ฟเวอร์ Cypress สามารถค้นหาองค์ประกอบและตรวจข้อความซ้ำในสายคำสั่งเดียว ขณะที่ Playwright รอความพร้อมของเป้าหมายก่อน action และรอผลผ่าน assertion ที่เหมาะสม ทั้งคู่ช่วยลดการใส่เวลารอคงที่ แต่เทสต์ยังต้องระบุผลที่ต้องการให้ชัด เช่น รายการสินค้าแสดงครบหรือข้อความยืนยันปรากฏแล้ว

การรอให้ปุ่มคลิกได้ไม่เท่ากับการรอให้กระบวนการซื้อเสร็จ หากแอปแสดงปุ่มก่อนผูกเหตุการณ์หรือก่อนข้อมูลพร้อม การคลิกอาจเกิดขึ้นโดยไม่มีผลตามที่คาด เทสต์ควรตรวจสถานะหลัง action ซึ่งผู้ใช้จะเห็นจริง มากกว่าสมมติว่าการผ่านขั้นตอนคลิกหมายถึง flow ทั้งหมดสำเร็จ

ภาษาและเบราว์เซอร์กำหนดขอบเขตงาน

Playwright มีทางเลือกสำหรับ JavaScript, TypeScript, Python, Java และ .NET ส่วน Cypress ใช้ JavaScript และ TypeScript เป็นหลัก สำหรับทีมที่เขียนระบบหรือชุดทดสอบด้วย Python, Java หรือ .NET อยู่แล้ว ทางเลือกภาษาของ Playwright ลดความจำเป็นต้องตั้งชุดทดสอบเว็บอีกภาษาหนึ่ง แต่ทีมยังต้องพิจารณาเครื่องมือรันทดสอบ ไลบรารี และทักษะผู้ดูแลในภาษาที่เลือก เพราะประสบการณ์ใช้งานแต่ละภาษาไม่เหมือนกันทุกส่วน

สำหรับทีม TypeScript ทั้งสองเครื่องมือเป็นตัวเลือกที่ใช้ภาษาเดียวกับโค้ดเว็บได้ ความแตกต่างที่เหลือจึงอยู่ที่รูปแบบคำสั่ง วิธีจัดชุดเทสต์ การตรวจผล และเบราว์เซอร์ที่ต้องครอบคลุม การเลือกจากภาษาล้วน ๆ ในกรณีนี้ให้คำตอบได้น้อยกว่าการดูว่าเทสต์ต้องจำลองผู้ใช้ในสภาพแวดล้อมใด

การตั้งค่าเบราว์เซอร์ของ Playwright รองรับ Chromium, Firefox และ WebKit เป็นโปรเจ็กต์ทดสอบ รวมทั้งเรียกใช้ Google Chrome หรือ Microsoft Edge ที่ติดตั้งในเครื่องได้ ความต่างระหว่าง Chromium กับ Chrome ที่ผู้ใช้ติดตั้งมีความหมายเมื่อเว็บพึ่งพาพฤติกรรมหรือส่วนประกอบของเบราว์เซอร์รุ่นที่เผยแพร่จริง จึงควรระบุให้ชัดว่าชุดทดสอบรับรองเอนจินหรือผลิตภัณฑ์เบราว์เซอร์ใด

รายการเบราว์เซอร์ของ Cypress ครอบคลุม Chrome, Edge และ Firefox ส่วน WebKit ยังเป็นการรองรับแบบทดลองที่ต้องเปิดใช้และติดตั้งส่วนประกอบเพิ่ม โดย Test Replay ใช้กับ WebKit ไม่ได้ หากการอนุมัติรุ่นเว็บต้องอาศัยการตรวจพฤติกรรมใน WebKit เป็นประจำ สถานะการรองรับและข้อจำกัดด้านการดีบักนี้มีน้ำหนักมากกว่าผลเวลาบน Chrome เพียงเบราว์เซอร์เดียว

WebKit ในเครื่องมือทดสอบช่วยตรวจพฤติกรรมของเอนจินที่เกี่ยวข้องกับ Safari แต่ไม่ควรถือว่าการรันบนระบบปฏิบัติการหนึ่งแทนการใช้งาน Safari จริงได้ทุกกรณี คุณสมบัติที่ขึ้นกับระบบ เช่น สื่อหรือฟอนต์ อาจให้ผลต่างกัน หากปัญหาที่ทีมต้องจับอยู่ตรงนั้น สภาพแวดล้อมที่ใช้รันต้องอยู่ในเงื่อนไขการเลือกเครื่องมือด้วย

ประสบการณ์ดีบักต่างกันตรงหลักฐานที่เห็น

Cypress แสดงคำสั่งและ assertion ตามลำดับใน Command Log จึงเหมาะกับการไล่ว่าสาย query หยุดตรงไหนและเงื่อนไขใดไม่ผ่านระหว่างพัฒนา ผู้เขียนเทสต์มองเห็นความสัมพันธ์ระหว่างการค้นหาองค์ประกอบ การทำ action และผลตรวจที่ตามมาได้ในลำดับเดียว ประโยชน์นี้เด่นเมื่อปัญหาเกิดบนหน้าเดียวและทำซ้ำได้ง่าย

ฝั่ง Playwright การแยกเงื่อนไขก่อน action ช่วยจำกัดคำถามเมื่อเทสต์ค้างรอองค์ประกอบ เช่น ปุ่มยังเคลื่อนไหว ถูกบัง หรือถูกปิดใช้งาน ในงานที่ข้ามหลายหน้า ร่องรอยการรันและสถานะของหน้าตามแต่ละ action มีประโยชน์ต่อการหาจุดที่ข้อมูลเริ่มเปลี่ยนจากที่คาด ความสะดวกไม่ได้วัดจากจำนวนภาพหรือแผงข้อมูลเท่านั้น แต่วัดจากเวลาที่ทีมใช้หาการเปลี่ยนสถานะผิดจุดแรก

ปัญหาที่ดูเหมือนเทสต์ไม่เสถียรอาจมาจากหลายชั้น หากองค์ประกอบไม่เคยปรากฏ ควรดูคำขอข้อมูลและเงื่อนไขแสดงผลของแอป หากองค์ประกอบปรากฏแต่ action ไม่เกิดผล ควรดูความพร้อมของตัวควบคุมและสถานะหลังคลิก ส่วนกรณีผ่านในเครื่องนักพัฒนาแต่ล้มใน CI ต้องตรวจความต่างของเบราว์เซอร์ ข้อมูลเริ่มต้น และระดับการรันพร้อมกัน เครื่องมือที่แสดงหลักฐานตรงกับปัญหาที่ทีมเจอบ่อยย่อมลดเวลาสืบหาสาเหตุได้มากกว่าเกณฑ์ความเร็วอย่างเดียว

ต้นทุน CI รวมมากกว่าเวลาของเทสต์หนึ่งกรณี

เมื่อจำกัดหน่วยความจำ การรันหลายงานพร้อมกันอาจทำให้เครื่อง CI ตึงตัว แม้แต่ละเทสต์จะจบเร็ว ผล RAM จากงานทดลองจึงเป็นสัญญาณให้วัดทรัพยากรควบคู่เวลาในสภาพแวดล้อมของทีม ไม่ใช่เหตุให้สรุปว่า Cypress จะกิน RAM เท่าเดิมในทุก pipeline เวลาที่ทีมได้รับผลจริงยังรวมการเตรียมสภาพแวดล้อม เปิดเบราว์เซอร์ และเก็บผลลัพธ์ด้วย

การขยายชุด Playwright ไปหลายเอนจินเพิ่มความครอบคลุม แต่เพิ่มงานรันและไฟล์ผลลัพธ์ตามไปด้วย Cypress ก็มีต้นทุนเปลี่ยนตามเบราว์เซอร์และจำนวนงานที่กระจายรัน จึงควรเทียบชุดทดสอบที่มีข้อมูลเริ่มต้นใกล้กัน ใช้เบราว์เซอร์เป้าหมายเดียวกัน และกำหนดระดับการรันพร้อมกันให้ชัด มิฉะนั้นเวลาที่ต่างกันอาจเป็นผลของการจัด pipeline มากกว่าตัวเฟรมเวิร์ก

เวลารันซ้ำมีผลเช่นกัน เทสต์ที่ล้มเพราะสภาพแวดล้อมแล้วต้องรันใหม่ทำให้เวลาจนได้ผลตัดสินใจยาวกว่าเวลารันครั้งที่ผ่าน การเพิ่ม timeout ทุกจุดอาจลดความล้มเหลวบางแบบ แต่จะยืดเวลารอเมื่อแอปผิดจริง ทีมจึงควรแยกเวลาที่ใช้ทำงาน เวลาที่รอเงื่อนไข และเวลาที่เสียไปกับการรันใหม่ก่อนตีความว่าเครื่องมือหนึ่งช้ากว่าอีกเครื่องมือ

เลือกจากข้อกำหนดที่ตัดสินผลได้จริง

• ทีม TypeScript ที่ต้องทดสอบ Chromium, Firefox และ WebKit เป็นงานประจำ: Playwright เป็นตัวเลือกแรกที่สอดคล้องกับขอบเขตนี้ แล้วค่อยวัดต้นทุนเมื่อเปิดหลายโปรเจ็กต์พร้อมกัน
• ทีม JavaScript หรือ TypeScript ที่ทำงานกับ Chrome, Edge หรือ Firefox และต้องการไล่ query กับ assertion ใน Command Log ระหว่างพัฒนา: Cypress มีรูปแบบดีบักที่ตรงความต้องการ โดยต้องตรวจสถานะ WebKit แยกต่างหากหากเว็บต้องรองรับเอนจินนั้น
• ทีมที่ดูแลเทสต์ด้วย Python, Java หรือ .NET อยู่แล้ว: ทางเลือกภาษาของ Playwright ช่วยให้ประเมินการใช้ทักษะเดิมได้โดยไม่ต้องตั้งชุด E2E บน JavaScript ทั้งหมด
• ทีมที่มีข้อจำกัดเวลาและ RAM ของ CI: ใช้ flow ตัวแทนทั้งงานสั้นและงานหลายขั้น วัดเวลาจนได้ผลที่ใช้ตัดสินใจพร้อมการใช้ทรัพยากร แล้วประเมินจำนวนงานที่รันพร้อมกันภายใต้เครื่องจริง

เมทริกซ์นี้ให้ลำดับความสำคัญต่างกันตามทีม หาก WebKit เป็นข้อกำหนดที่ต่อรองไม่ได้ ความเร็วบน Chrome ไม่มีทางชดเชยการครอบคลุมที่ขาดไป หากเบราว์เซอร์เป้าหมายอยู่ในขอบเขตของทั้งคู่ ภาษาและวิธีดีบักจะมีน้ำหนักมากขึ้น และหาก CI เป็นคอขวด ผลเวลาต่อกรณีต้องอ่านคู่กับหน่วยความจำและเวลารันทั้งชุด การเลือกที่ดีจึงเริ่มจากข้อกำหนดของชุดทดสอบ แล้วใช้ผลวัดความเร็วตอบคำถามที่เหลือ