Đã đăng vào khoảng 6 giờ trước 5 phút đọc

Chuyển từ Cucumber sang Playwright: Lựa chọn tối ưu cho Developer trong Automation Testing

Nếu bạn đã từng làm Automation Testing, chắc hẳn bạn không còn lạ lẫm với Cucumber và triết lý BDD (Behavior-Driven Development). Việc viết test bằng ngôn ngữ tự nhiên (Gherkin: Given, When, Then) từng được xem là "chén thánh" giúp kết nối BA, PO và Developer.

Tuy nhiên, thực tế phũ phàng là ở nhiều dự án, chỉ có Dev/QA tự viết file feature và tự maintain chúng. Việc sinh ra thêm một tầng dịch (Gherkin -> Code) bỗng dưng trở thành gánh nặng. Nếu bạn đang tìm kiếm một hướng đi thiên về Engineering/Developer hơn, Playwright chính là câu trả lời.

1. Tại sao Developer lại "ngán" Cucumber? Hãy nhìn vào Code!

Cucumber bản chất không phải là tool để test web, nó là tool để giao tiếp. Để click một nút trên web, bạn phải làm 2 việc:

Đây là cách Cucumber hoạt động (Gây mệt mỏi khi bảo trì):

# Phải viết file text này
Feature: Login
  Scenario: User can login
    Given I navigate to the login page
    When I enter "admin" into the email field
    And I click login

// Sau đó phải viết thêm file Step Definition này để map code
Given('I navigate to the login page', async () => { /* code */ });
When('I enter {string} into the email field', async (user) => { /* code */ });

Còn đây là cách Playwright hoạt động (Code-first, gọn gàng):

test('User can login', async ({ page }) => {
  await page.goto('https://myapp.com/login');
  await page.getByLabel('Email').fill('admin');
  await page.getByRole('button', { name: 'Login' }).click();
});

Gọn gàng trong 1 file duy nhất. Hỗ trợ auto-complete (gợi ý code) cực tốt trong VS Code. Không còn cảnh chạy đi tìm xem cái step text này nó đang map với cái function nào ở file nào nữa!

2. Deep Dive: Chuyện gì xảy ra bên dưới Playwright?

Khác với Selenium (sử dụng giao thức WebDriver gửi các HTTP request), kiến trúc của Playwright hiện đại và tối ưu hơn rất nhiều.

Toàn cảnh Workflow: Từ Engine đến Report

Để dễ hình dung nhất, dưới đây là sơ đồ thể hiện luồng hoạt động từ lúc khởi chạy Test Runner cho đến khi sinh ra file Report:

A. Kiến trúc kết nối trực tiếp qua WebSocket

Playwright sử dụng giao thức CDP (Chrome DevTools Protocol). Nó mở một kết nối WebSocket trực tiếp vào thẳng engine của trình duyệt. Điều này tạo ra giao tiếp 2 chiều (bi-directional): Playwright gửi lệnh đi cực nhanh và Trình duyệt chủ động "báo cáo" lại cho Playwright các sự kiện ngay lập tức.

B. Cơ chế Auto-waiting Thần thánh

Flaky test (test chập chờn) là nỗi ám ảnh. Playwright giải quyết triệt để bằng cơ chế Actionability Checks. Trước khi click, nó tự động chờ phần tử đạt đủ 4 điều kiện:

Nằm trong DOM.
Hiển thị (Visible).
Đứng yên (Stable - không bị animation).
Sẵn sàng nhận sự kiện. Điều này giúp bạn loại bỏ tới 99% các đoạn code sleep(5000) (hardcoded wait) cứng nhắc. Tất nhiên, Playwright vẫn cung cấp hàm page.waitForTimeout() cho những case đặc thù (như chờ một job chạy ngầm dưới backend hoặc webhook bên thứ 3), nhưng trong hầu hết các tương tác UI thông thường, framework đã tự động xử lý việc chờ đợi một cách thông minh.

C. Browser Contexts - Cách ly siêu tốc

Khởi động cả một cái Browser rất tốn tài nguyên. Playwright dùng Context (giống như một tab Ẩn danh mới tinh). Playwright chỉ bật Browser 1 lần, sau đó tạo ra hàng chục Context cho các bài test độc lập.

3. Trải nghiệm Debug tuyệt vời với Trace Viewer

Flaky test hay lỗi trên CI/CD luôn là ác mộng vì rất khó tái hiện. Nhưng Playwright cung cấp một công cụ mạnh mẽ: Trace Viewer

Khi cấu hình lưu Trace, Playwright sẽ ghi lại toàn bộ quá trình chạy test. Nếu test fail, bạn mở file trace lên và có thể:

Xem lại DOM thật của trang web ở ngay khoảnh khắc test bị fail (Time-travel).
Xem chi tiết Network tab (request nào gọi, response trả về gì).
Trỏ chuột vào từng dòng code để xem trạng thái màn hình lúc đó. Nó giống như một cuốn băng ghi hình toàn diện giúp bạn tìm ra nguyên nhân lỗi chỉ trong vài phút.

Lời kết: Cucumber không tệ, chỉ là bài toán đã khác

Cucumber và triết lý BDD sinh ra để giải quyết bài toán giao tiếp giữa đội ngũ Business (PO, BA) và Developer. Nếu dự án của bạn có quy trình BDD chuẩn mực, mọi người cùng đọc và thống nhất qua file .feature, thì Cucumber vẫn là một công cụ tuyệt vời.

Nhưng thực tế, phần lớn các dự án chỉ có kỹ sư tự viết Gherkin và tự maintain. Lúc này, tầng Gherkin trở thành một lớp abstraction dư thừa, làm chậm tốc độ phát triển và tăng chi phí bảo trì. Nếu bạn là một Developer/SDET thuần túy, muốn tập trung vào logic, độ ổn định và tốc độ chạy test, Playwright là một công cụ sinh ra dành cho bạn.

Nguồn: Why Developers Are Abandoning Cucumber for Playwright