WebDriver BiDi: Deep Dive Cho Automation Tester

WebDriver BiDi mở rộng browser automation từ mô hình request-response sang giao tiếp hai chiều, event-driven. Bài viết này giúp automation tester có nền tảng WebDriver thiết kế flow theo dõi navigation và network, đồng thời biết giới hạn của protocol đang tiếp tục hoàn thiện.

WebDriver BiDi giải quyết giới hạn nào của automation truyền thống?

Bài này dành cho automation tester hoặc QA engineer đã biết WebDriver session, locator, assertion, HTTP cơ bản và JavaScript hoặc TypeScript async/await.

Sau bài này, tester cần đạt được các outcome sau:

WebDriver classic hoạt động theo chuỗi client gửi request rồi chờ browser trả response, phù hợp với thao tác như navigate, find element và click.

Nhưng các tình huống như “báo ngay khi navigation fail”, “ghi lại console error trong lúc test” hoặc “chặn request trước khi server nhận” cần một kênh để browser chủ động phát tín hiệu về client.

Đặc tả WebDriver BiDi của W3C định nghĩa một protocol bidirectional để remote control user agents. Selenium WebDriver BiDi]Selenium WebDriver BiDi]MDN diễn giải BiDi là giao tiếp event-driven giữa automation client và browser, khác mô hình HTTP request-response của WebDriver classic và hỗ trợ WebSocket-based communication.

Protocol BiDi gồm những lớp nào cần hiểu trước khi code?

Không nên bắt đầu bằng việc copy một snippet intercept request. Trước tiên, tester cần tách bốn khái niệm: session, module, command và event.

Đặc tả hiện chia protocol thành các phần infrastructure, protocol definition, session, modules, commands, errors, events và transport. Cách chia này quan trọng vì một test có thể vừa gửi command navigate vừa subscribe event load hoặc network.

Nếu chỉ nhìn API cấp cao, tester dễ không nhận ra failure có thể nằm ở lifecycle subscription, browser support hoặc mapping của library.

Một nguyên tắc thực dụng là viết test intent trước rồi mới chọn API.

Ví dụ intent “khi submit login, không gửi request đến analytics nếu user từ chối consent” cần network event hoặc request handler, trong khi intent “page đã hiển thị message sau khi navigation hoàn tất” có thể dùng browsingContext

event kết hợp assertion trên DOM. Hai intent này khác nhau dù đều xuất hiện trong cùng một browser flow.

Bật BiDi trong Selenium và kiểm tra capability thế nào?

Selenium docs yêu cầu tester bật BiDi trong Options trước khi dùng các tính năng tương ứng.

Chi tiết setup phụ thuộc ngôn ngữ và browser, vì vậy không nên coi một snippet JavaScript là contract chung cho Java, Python, C# hoặc Ruby. Hãy bắt đầu bằng trang Selenium WebDriver BiDi và kiểm tra phần enabling BiDi của binding đang dùng.

Với TypeScript, tester cần kiểm tra ba điểm trước khi viết assertion: phiên bản Selenium có expose wrapper cho module cần thiết hay chưa, browser và driver có capability tương ứng hay không, và test runner có xử lý lifecycle bất đồng bộ cùng cleanup event listener sau mỗi test hay không.

Không nên kết luận “BiDi không hoạt động” chỉ vì wrapper thiếu method.

W3C protocol, browser implementation, driver và Selenium binding là bốn lớp khác nhau; một capability có thể tồn tại trong đặc tả nhưng chưa được binding expose, hoặc đã expose nhưng implementation đang được theo dõi qua issue.

Tài liệu network của Selenium hiện liên kết việc triển khai với issue #13993, vì vậy tester cần kiểm tra release và browser matrix thay vì ghi hard-code một claim hỗ trợ tuyệt đối.

Network interception trong BiDi dùng cho use case nào?

Network namespace có giá trị khi tester cần quan sát hoặc điều chỉnh traffic trong một browser flow. Selenium mô tả authentication handlers để xử lý authentication request như Basic Auth hoặc Digest Auth.

Request handlers có thể intercept và thay đổi outgoing request trước khi gửi, còn response handlers làm việc với response để kiểm tra hoặc điều chỉnh header, status code và content.

Một use case phù hợp là kiểm tra UI phản ứng ra sao khi API profile trả 401, 429 hoặc response chậm.

Tester không cần dựng một backend riêng cho từng biến thể, nhưng phải phân biệt giữa mô phỏng lỗi có chủ đích và hành vi thật của môi trường; nếu handler sửa response, evidence phải ghi rõ đó là

synthetic response để người đọc không nhầm với lỗi production.

Use case thứ hai là xác minh request contract: khi user submit form, tester quan sát method, URL, header cần thiết và body trước khi request rời browser.

Đây là lớp kiểm tra bổ sung cho UI assertion, không thay thế API Testing cơ bản hoặc kiểm tra service độc lập.

Nếu mục tiêu là kiểm tra backend rule, hãy giữ boundary rõ ràng thay vì nhồi tất cả vào browser test.

Subscribe event và cleanup thế nào để test không flaky?

Event-driven test có rủi ro race condition: nếu subscribe sau khi action đã xảy ra, tester có thể bỏ lỡ event và nhận false failure. Nếu listener sống quá lâu, event của test trước có thể chảy sang test sau.

Vì vậy hãy đặt subscription trước action, lọc đúng context hoặc request, chờ event với timeout hợp lý và luôn cleanup trong teardown.

Một flow có thể viết theo thứ tự: tạo session, subscribe event cần thiết, tạo promise chờ event với predicate cụ thể, thực hiện navigate hoặc submit, await event, kiểm tra payload, hủy subscription và đóng session.

Predicate không nên chỉ là “có một response”, mà nên kiểm tra context id, URL pattern, method hoặc request id để tránh bắt nhầm traffic của resource khác.

Timeout cũng cần có lý do: quá ngắn sẽ tạo false failure khi CI chậm, còn quá dài sẽ che giấu lỗi thực sự và làm suite mất tín hiệu.

Nếu test nhiều browser, hãy ghi nhận sự khác nhau về event order và capability thay vì ép mọi implementation có cùng timing tuyệt đối.

Đoạn trên là pseudo-code mô tả thứ tự và predicate, không phải API copy-paste cho mọi Selenium binding. Trong code thật, tester phải dùng đúng interface của binding và quản lý cleanup theo test runner.

Cách trình bày này cố ý tách design pattern khỏi chi tiết wrapper, vì wrapper có thể thay đổi nhanh hơn protocol.

BiDi khác CDP ra sao khi chọn chiến lược automation?

CDP là protocol gắn chặt với Chrome DevTools ecosystem, trong khi WebDriver BiDi hướng tới một chuẩn WebDriver hai chiều có khả năng dùng qua nhiều browser implementation.

Điều này không có nghĩa BiDi ngay lập tức thay thế mọi khả năng CDP; tester cần so sánh use case, browser matrix, độ ổn định của binding và yêu cầu portability.

Selenium đặt BiDi cạnh phần CDP trong tài liệu để người dùng hiểu lộ trình chuyển sang lựa chọn standards-based. Với team chỉ chạy Chrome và cần một capability DevTools đặc thù, CDP có thể vẫn phù hợp.

Với team cần giảm phụ thuộc vendor và theo dõi event theo mô hình WebDriver, BiDi đáng được đánh giá bằng một spike nhỏ có acceptance criteria rõ ràng.

Đánh giá BiDi trong CI mà không biến test thành hộp đen

Một proof of concept có giá trị nên ghi lại browser, driver, Selenium binding, capability đã bật, event đã subscribe và kết quả theo từng run.

Đừng chỉ báo “test pass” vì phần quan trọng của BiDi là evidence ở giữa flow; khi có failure, cần biết command nào đã gửi, event nào không đến, payload có gì và cleanup có chạy hay không.

Hãy thêm các assertion chống false positive. Nếu request bị chặn, xác nhận request thực sự không rời browser hoặc response không được dùng như dữ liệu thật.

Nếu nhận 401, kiểm tra UI state và API state có nhất quán. Nếu theo dõi log, phân biệt error do ứng dụng với error do browser hoặc test harness.

Với suite lớn, event log có thể làm report khó đọc. Chỉ lưu payload cần cho triage, che thông tin nhạy cảm và dùng correlation id để nối action với event.

Kỹ thuật này gần với tư duy test observability cho người mới, nhưng bài này tập trung vào protocol và event boundary của browser automation, không phải thiết kế observability cho toàn hệ thống.

Tổng kết

WebDriver BiDi là protocol hai chiều, event-driven, nhưng tài liệu W3C hiện vẫn là Working Draft và implementation cần được kiểm tra theo browser, driver và binding.

Thiết kế test nên bắt đầu từ intent, sau đó chọn module, event, subscription scope và cleanup strategy.

Network handlers phù hợp cho kiểm tra authentication, request contract và phản ứng UI trước response lỗi, nhưng không thay thế API test ở boundary service.

Nếu team đang xử lý flaky test hoặc cần quan sát evidence trong automation, hãy đọc cách khắc phục flaky test và bài xây pipeline kiểm thử AI với OpenTelemetry để phân biệt protocol event với test observability.

Nếu phải chọn một use case để chạy spike WebDriver BiDi tuần này, team sẽ ưu tiên bắt navigation event, kiểm tra network response hay thu console log, và acceptance criteria cụ thể là gì?