Automation Giới thiệu Playwright - Browser Automation

Trong thế giới phát triển phần mềm hiện đại, mọi thứ đang thay đổi với tốc độ chóng mặt. Các đội ngũ kỹ sư liên tục bị đặt dưới áp lực phải di chuyển nhanh hơn, kiểm thử thông minh hơn và phát hành sản phẩm với sự tự tin cao nhất, thường là trong điều kiện nhân lực ít hơn và tiến độ vô cùng eo hẹp.
Kiểm thử thủ công, dù luôn có giá trị không thể thay thế trong việc đánh giá trải nghiệm người dùng, nhưng lại trở nên quá chậm chạp và dễ xảy ra sai sót trước quy mô khổng lồ của các ứng dụng ngày nay.
Để theo kịp tốc độ phát triển, kiểm thử tự động (Automated Testing) ra đời như một mảnh ghép bắt buộc. Tự động hóa mang theo lời hứa về tốc độ và sự an tâm tuyệt đối, nhưng thực tế đôi khi lại rất phũ phàng: thay vì giải phóng sức lao động, nó lại mang đến sự bực bội và những chuỗi ngày gỡ lỗi (debugging) dài đằng đẵng.
Nguyên nhân sâu xa đến từ sự tiến hóa của chính nền tảng Web. Những trang web tĩnh đơn giản của quá khứ nay đã trở thành các ứng dụng JavaScript phức tạp, liên tục tải dữ liệu ngầm và chứa đầy các hiệu ứng chuyển động.
Khi đối mặt với sự phức tạp này, các công cụ kiểm thử thế hệ cũ dần bộc lộ sự đuối sức. Chúng liên tục tạo ra các "flaky test" – những bài kiểm thử chạy lúc thành công lúc thất bại một cách khó hiểu, khiến các kỹ sư phải chắp vá bằng những lệnh chờ (sleep) thủ công đầy mệt mỏi.
Điều này không chỉ làm chậm quá trình phát hành mà còn bào mòn dần niềm tin của cả đội ngũ vào hệ thống tự động hóa.
Đó chính là bối cảnh mà Playwright xuất hiện. Công cụ này không chỉ đơn thuần là một giải pháp kiểm thử mới, mà nó đại diện cho một sự dịch chuyển hoàn toàn trong cách chúng ta tiếp cận tự động hóa, tính ổn định và trải nghiệm của lập trình viên. Nó được sinh ra để thấu hiểu và thích ứng với sự khó lường của web hiện đại
1. Playwright là gì và nguyên lý hoạt động
Playwright là một thư viện tự động hóa trình duyệt (browser automation) mã nguồn mở do Microsoft phát triển. Nó ra đời nhằm giải quyết những hạn chế của Selenium WebDriver khi đối mặt với các ứng dụng web hiện đại những trang web tải dữ liệu bất đồng bộ (async), chứa nhiều hiệu ứng chuyển động (animation) và kết xuất thành phần động (dynamic rendering).
Thay vì điều khiển trình duyệt gián tiếp qua lớp mạng HTTP có độ trễ cao như Selenium, Playwright kết nối trực tiếp vào "bộ não" của trình duyệt thông qua giao thức CDP (Chrome DevTools Protocol) bằng một kết nối WebSocket liên tục. Mỗi lệnh từ mã nguồn của bạn (ví dụ: click, gõ phím) sẽ được dịch thành chuỗi JSON và gửi trực tiếp tới engine của trình duyệt để thực thi trong vài mili-giây. Đối với Firefox và WebKit (Safari), Playwright sử dụng các bản dựng (custom builds) trình duyệt riêng biệt đã được bổ sung một giao thức giao tiếp tương tự như CDP.

2. Mô hình kiến trúc phân cấp 4 Tầng
Mọi hàm và phương thức trong API của Playwright đều được xây dựng trên một mô hình phân cấp tài nguyên chặt chẽ. Việc hiểu sai mô hình này thường dẫn đến lỗi không tìm thấy phần tử.

1. Browser (Trình duyệt): Là lớp ngoài cùng, đại diện cho một tiến trình (process) của phần mềm trình duyệt đang chạy (Chromium, Firefox, hoặc WebKit). Bạn không thể mở trực tiếp một trang web từ lớp này.
2. BrowserContext (Ngữ cảnh): Đây là khái niệm cốt lõi nhất. Mỗi Context là một phiên làm việc hoàn toàn độc lập, tương tự như một "cửa sổ ẩn danh" (Incognito) riêng biệt. Mỗi Context có bộ chứa cookie, bộ nhớ cục bộ (localStorage) và bộ nhớ phiên (sessionStorage) độc lập. Nhờ đó, bạn có thể tạo hàng chục Context để chạy song song nhiều bài kiểm thử với các tài khoản đăng nhập khác nhau trên cùng một Browser mà không bị xung đột dữ liệu.
3. Page (Trang): Đại diện cho một thẻ (tab) bên trong Context. Đây là nơi bạn thực thi phần lớn các lệnh tương tác như điền form, nhấp chuột, hoặc điều hướng URL (thông qua đối tượng page).
4. Frame (Khung hiển thị): Mỗi Page chứa ít nhất một khung chính (main frame). Nếu trang web nhúng các thành phần từ bên thứ ba (như khung nhập thẻ tín dụng của cổng thanh toán, bản đồ), chúng sẽ nằm trong các iframe. Theo mặc định, Playwright chỉ quét phần tử ở khung chính; nếu phần tử nằm trong iframe, bạn bắt buộc phải dùng hàm page.frameLocator() để trỏ vào đúng khung đó trước khi tương tác.

3. Cơ chế tự động chờ (Auto-waiting) và timeout
Trong quá trình xây dựng các kịch bản tự động hóa, một khuôn mẫu (pattern) thường thấy là: thực hiện một thao tác, sau đó sử dụng các lệnh chờ thủ công (như sleep) để đợi trang web phản ứng. Tuy nhiên, đây là một anti-pattern kinh điển. Nếu thời gian chờ được thiết lập quá ngắn, trang chưa kịp tải dữ liệu xong sẽ dẫn đến lỗi thực thi; ngược lại, nếu thời gian chờ quá dài, kịch bản kiểm thử sẽ bị chậm lại một cách lãng phí. Trên thực tế, không thể xác định được một con số 'vừa đủ' cho thời gian chờ này vì tốc độ mạng và thời gian phản hồi của hệ thống luôn biến động
Thay vì lập trình viên tự ước lượng thời gian chờ, trước khi thực hiện bất kỳ hành động nào (click, fill, check...), Playwright tự động kiểm tra 6 điều kiện dưới đây. :

1. Attached : Phần tử phải tồn tại trong cây DOM. Nếu đang chờ API trả dữ liệu, Playwright tự đợi cho đến khi HTML xuất hiện.
2. Visible (Hiển thị): Phần tử không bị ẩn bởi CSS (không chứa thuộc tính display: none hay visibility: hidden) và phải có kích thước lớn hơn 0x0 pixel.
3. Stable (Ổn định): Phần tử không được nằm trong trạng thái đang chuyển động hoặc thực thi hiệu ứng hoạt hình. Playwright tính toán tọa độ của phần tử trong hai khung hình liên tiếp, nếu tọa độ không đổi, nó mới được coi là ổn định.
4. Enabled (Được kích hoạt): Phần tử (đặc biệt là input, button) không chứa thuộc tính disabled.
5. Editable (Có thể chỉnh sửa): Áp dụng riêng cho lệnh nhập văn bản (fill). Phần tử không được chứa thuộc tính readonly.
6. Receives events (Sẵn sàng nhận sự kiện): Playwright sẽ kiểm tra tọa độ tâm của phần tử. Nếu tại điểm đó, phần tử đang bị che khuất bởi một thành phần khác (ví dụ: màn hình mờ báo hiệu "Đang tải dữ liệu..." đè lên trên), lệnh click sẽ bị tạm dừng cho đến khi lớp che phủ biến mất.

Để quản lý quá trình chờ này, Playwright dùng hệ thống Timeout phân cấp: Test timeout (thời gian tối đa cho toàn bộ kịch bản, mặc định 30s), Action timeout (thời gian tối đa cho 1 lệnh click/fill, mặc định 30s), và Navigation timeout (thời gian tối đa chờ tải trang). Nếu quá thời gian này mà 6 điều kiện chưa thỏa mãn, hệ thống mới ném ra lỗi (throw error).

4. Định vị phần tử (Locator Strategy)
Trong các công cụ cũ (như Selenium), "Selector" là việc tìm và lưu trực tiếp một nút HTML tại một thời điểm. Nếu trang web tự động làm mới giao diện (re-render), nút đó trở nên cũ kĩ (stale) và gây lỗi. Locator của Playwright là một "công thức toán học". Mỗi khi có lệnh tương tác, Playwright dùng công thức này để rà soát lại HTML từ đầu, đảm bảo luôn tìm được phần tử mới nhất.
Playwright áp dụng Chế độ nghiêm ngặt (Strict mode): Nếu công thức Locator tìm thấy từ 2 phần tử trở lên trên màn hình (ví dụ: có 2 nút "Đăng nhập"), nó sẽ lập tức báo lỗi thay vì tự ý chọn phần tử đầu tiên. Điều này ép lập trình viên phải viết mã chính xác tuyệt đối.
Hệ thống ưu tiên tìm kiếm từ cao xuống thấp

5. Phương pháp gỡ lỗi (Debugging) chuyên nghiệp
Khi kịch bản thất bại, Playwright cung cấp bộ công cụ mạnh mẽ để truy vết:

1. Chụp ảnh màn hình (Screenshot): Phản xạ đầu tiên của kỹ sư tự động hóa. Đặt lệnh await page.screenshot({ path: 'debug.png' }) ngay trước dòng báo lỗi để xem màn hình thực tế lúc đó đang bị gì (bảng thông báo che khuất, trang bị trắng...).
2. Playwright Inspector: Kích hoạt bằng biến môi trường PWDEBUG=1. Công cụ này sẽ mở một cửa sổ phụ, cho phép chạy chậm (step-over) từng dòng mã để theo dõi hệ thống đang cố tìm Locator nào trên giao diện.
3. Trace Viewer: Công cụ chẩn đoán tối thượng. Playwright sẽ lưu toàn bộ quá trình chạy thành một tệp .zip, bao gồm: mọi ảnh chụp màn hình từng mili-giây, mọi gói tin mạng được tải, cấu trúc HTML (DOM snapshot) tại thời điểm lỗi, và logs của console. Bạn có thể mở tệp này để tua lại (replay) toàn bộ quá trình như xem phim.

6. Playwright trong DevOps
Khi mới nghe đến Playwright, hầu hết mọi người nghĩ đến testing, viết test case để kiểm tra UI của ứng dụng. Đây đúng là use case chính, nhưng Playwright có nhiều ứng dụng khác trong hệ sinh thái DevOps và IT Operations.
Trong IT Operations, Playwright có thể được dùng như một 'robotic process automation' (RPA) cho web, tự động hóa các tác vụ lặp đi lặp lại trên portal mà không có API: tạo ticket, điền form, đọc báo cáo, export data.
Trong monitoring, Playwright thực hiện synthetic monitoring chạy 'giả lập người dùng thật' định kỳ để kiểm tra portal có hoạt động bình thường không, login có được không, các chức năng quan trọng có responsive không