8 เครื่องมือ Debug ใน Playwright ที่มือใหม่ควรรู้

เคยไหมครับ? Test รันผ่านบนเครื่องตัวเอง แต่พอขึ้น CI กลับ Fail แบบหาสาเหตุไม่เจอ ปัญหานี้แก้ได้ง่ายขึ้นมาก ถ้ารู้จักเครื่องมือ Debug ที่ Playwright เตรียมไว้ให้ครบชุด ตั้งแต่ย้อนดูการทำงานทั้งหมดของ Test ไปจนถึงหยุดดูทีละ Step แบบ Real-time

1. Trace Viewer — ย้อนดูทุกการทำงานของ Test

คืออะไร: เหมือนกล้องวงจรปิดของการรัน Test บันทึกทุกอย่างไว้ (Screenshot, DOM, Network, Console) ให้เปิดย้อนดูได้ทีหลัง โดยไม่ต้องรันซ้ำ

เปิดใช้งาน ใน playwright.config.ts:

export default defineConfig({
  use: {
    trace: 'retain-on-failure',
  },
});

ตัวเลือกที่ใช้บ่อย:

• retain-on-failure — เก็บเฉพาะ Test ที่ Fail (แนะนำ เหมาะกับ CI เพราะประหยัดพื้นที่)
• on-first-retry — เก็บเฉพาะตอน Retry ครั้งแรก
• on — เก็บทุก Test แม้ผ่าน (ไฟล์ใหญ่ ใช้เฉพาะตอน Debug ละเอียดจริง ๆ)

เปิดดู Trace:

npx playwright show-trace trace.zip

เหมาะกับ: Test ที่ Fail บน CI/CD และปัญหาที่เกิดเป็นบางครั้ง (Flaky Test) เพราะเราไม่ต้องรอให้ Fail ซ้ำอีกรอบ

2. UI Mode — ศูนย์รวมการเขียนและ Debug Test

คืออะไร: หน้าจอ GUI สำหรับรัน Test แบบ Interactive เห็นผลทันที ไม่ต้องสลับไปมาระหว่าง Terminal กับโค้ด

npx playwright test --ui

ข้อดี: เลือกรันเฉพาะไฟล์/เฉพาะ Test ได้, Re-run ง่าย, เห็นผล Real-time, กด Trace ดูได้ทันทีที่ Fail โดยไม่ต้องพิมพ์คำสั่งแยก

เหมาะกับ: ช่วงเขียน Test ใหม่ หรือ Debug หลายไฟล์พร้อมกัน

3. Code Generator — ให้ Playwright ช่วยเขียนโค้ดแทน

คืออะไร: เครื่องมือที่บันทึกการคลิก/พิมพ์บนเว็บจริง แล้วแปลงเป็น Playwright Code ให้อัตโนมัติ รวมถึงช่วยหา Locator ที่เสถียร

npx playwright codegen https://example.com

เหมาะกับ: มือใหม่ที่ยังไม่คุ้นกับ Selector หรือใครที่อยากลดเวลาหา Locator ที่แม่นยำ

4. Debug Mode + Playwright Inspector — หยุดดูทีละ Step

คืออะไร: สองตัวนี้เป็นชุดเดียวกัน — สั่ง Debug Mode แล้ว Playwright Inspector คือหน้าต่างที่เด้งขึ้นมาให้ควบคุม เดินหน้า/ถอยหลัง/หยุดพัก Test ได้ทีละคำสั่ง พร้อมดู Locator ที่ Test เลือกใช้จริง

npx playwright test --debug

หรือ

PWDEBUG=1 npx playwright test

หากอยากหยุดที่จุดใดจุดหนึ่งในโค้ดโดยเฉพาะ ใช้ page.pause():

await page.goto('https://example.com');
await page.pause(); // <--- หยุดตรงนี้ให้ตรวจสอบ
await page.click('button');

เหมาะกับ: ตามหาสาเหตุที่ Element หาไม่เจอ หรือ Action ทำงานผิดจังหวะ เพราะเห็นทุก Step ก่อนมันจะพัง

5. Console Log & Network Debugging — เช็ค Error เบื้องหลัง

คืออะไร: ดัก Log และ Network Request/Response ที่เกิดขึ้นในหน้าเว็บระหว่าง Test รัน เพื่อดูว่า Test Fail เพราะ Bug ของเว็บเอง หรือ API มีปัญหา

page.on('console', msg => console.log(msg.text()));
page.on('pageerror', error => console.log(error.message));
page.on('request', request => console.log(request.url()));
page.on('response', response => console.log(response.status(), response.url()));

เหมาะกับ: สงสัยว่า Test Fail เพราะ JavaScript Error หรือ API ตอบผิดปกติ

6. Screenshot & Video — หลักฐานภาพตอน Fail

คืออะไร: บันทึกภาพนิ่งหรือวิดีโอของหน้าจอตอน Test ล้ม ช่วยตอบคำถามที่ Log อย่างเดียวตอบไม่ได้ เช่น “หน้าตาตอนนั้นเป็นยังไง”

use: {
  screenshot: 'only-on-failure',
  video: 'retain-on-failure',
}

ช่วยเช็คได้ว่า: Popup ขึ้นมาบังหรือไม่, หน้าโหลดค้างหรือเปล่า, UI เปลี่ยนไปจากที่โค้ดคาดไว้หรือไม่

เหมาะกับ: Debug บน CI/CD ที่เราไม่เห็นหน้าจอจริง

7. SlowMo — ดูการทำงานแบบสโลว์โมชัน

คืออะไร: สั่งให้ Browser หน่วงเวลาก่อนทำแต่ละ Action ทำให้มองตามทันว่า Test คลิกอะไร พิมพ์อะไรบ้าง แทนที่จะเห็นแค่ภาพวูบเดียว

const browser = await chromium.launch({
  headless: false,
  slowMo: 500, // หน่วง 500ms ต่อ Action
});

เหมาะกับ: สังเกตการทำงานแบบ Real-time, เช็ค Animation, หรือ Demo ให้ทีมดู

สรุป: เลือกใช้ตามสถานการณ์

ไม่จำเป็นต้องใช้ทุกตัวพร้อมกัน เลือกให้เหมาะกับปัญหาตรงหน้า จะช่วยลดเวลา Debug ได้เยอะ โดยเฉพาะปัญหาที่เกิดเฉพาะบน CI/CD หรือเกิดเป็นบางครั้ง