Waits & xử lý bất đồng bộ trong automation cho người mới (có code Playwright chạy được)

1. Tóm tắt nhanh & màn hình bạn sẽ test

Chào bạn mới! Khi mới học automation, bạn sẽ sớm gặp một hiện tượng khó chịu: test chạy pass lúc này, fail lúc khác, dù bạn không hề sửa gì. Thủ phạm phổ biến nhất chính là 'thời gian' — cụ thể là việc trang web tải dữ liệu bất đồng bộ (gọi API, render danh sách sản phẩm...) mất một khoảng thời gian không cố định. Nếu script automation thao tác 'quá sớm', trước khi dữ liệu thật sự sẵn sàng, test sẽ fail dù ứng dụng hoàn toàn không có lỗi. Bài này giúp bạn hiểu đúng cơ chế 'chờ' trong automation, qua trang sản phẩm ShopEasy — nơi danh sách sản phẩm chỉ xuất hiện sau khi gọi API xong.

2. Vấn đề: vì sao test tự động hay 'flaky' vì thời gian

Web hiện đại hiếm khi tải xong mọi thứ ngay lập tức. Khi bạn mở trang sản phẩm ShopEasy, trình duyệt trả về khung HTML rỗng trước, rồi JavaScript mới gọi API lấy danh sách sản phẩm, và chỉ khi API trả lời xong, danh sách mới được render lên màn hình. Khoảng thời gian giữa 'mở trang' và 'dữ liệu thật sự sẵn sàng' không cố định — nó phụ thuộc tốc độ mạng, tải server, và có thể khác nhau ở mỗi lần chạy dù cùng một môi trường.

Script automation thường chạy nhanh hơn nhiều so với tốc độ con người click chuột — và đôi khi còn nhanh hơn cả tốc độ trang web render xong. Nếu script viết '.product-item' ngay sau page.goto(), có khả năng thật cao là lúc đó server vẫn đang xử lý response, danh sách sản phẩm chưa hề tồn tại trên DOM. Kết quả: test báo lỗi 'element not found', dù chỉ vài trăm mili-giây sau đó, phần tử này xuất hiện hoàn toàn bình thường. Đây chính là bản chất của một race condition trong automation — automation 'đến trước' dữ liệu thật.

3. Sleep cứng (hard sleep) — vì sao là cách tệ nhất

Phản xạ tự nhiên của người mới khi gặp lỗi 'element not found' là thêm một dòng dừng cứng: page.waitForTimeout(2000) — chờ đúng 2 giây rồi mới thao tác tiếp. Cách này có vẻ giải quyết được vấn đề trước mắt, nhưng thực chất chỉ đang 'đoán mò' một con số, không hề dựa vào trạng thái thực tế của trang. Vấn đề lộ ra ngay khi tốc độ hệ thống thay đổi — mà điều này gần như chắc chắn sẽ xảy ra giữa các lần chạy khác nhau.

• 📌 Sleep cứng dùng 1 con số cố định, không phản ánh tốc độ thực tế đang đổi liên tục
• 📌 Chờ theo điều kiện luôn 'vừa đủ': nhanh thì đi ngay, chậm thì vẫn đợi đúng

4. Implicit wait là gì & vì sao có giới hạn

Implicit wait là một cấu hình đặt MỘT LẦN ở cấp trình duyệt hoặc phiên làm việc: 'nếu tìm không thấy phần tử ngay, hãy tự động thử lại trong tối đa N giây trước khi báo lỗi'. Cấu hình này áp dụng ngầm cho MỌI lần tìm phần tử trong suốt phiên, bạn không cần viết lại ở từng dòng code. Đây là cách tiếp cận phổ biến trong các công cụ automation thế hệ cũ như Selenium WebDriver truyền thống.

Giới hạn lớn nhất của implicit wait là tính 'tất cả hoặc không có gì': cùng một con số N giây áp dụng cho MỌI phần tử, dù đó là một nút bấm luôn có sẵn ngay lập tức, hay một danh sách sản phẩm cần chờ API trả lời. Nếu N quá ngắn, những phần tử cần chờ lâu vẫn fail; nếu N quá dài, mọi lần tìm phần tử không thấy (kể cả lỗi thật của ứng dụng) đều phải đợi rất lâu mới báo lỗi, làm chậm cả bộ test. Ngoài ra, khi trộn implicit wait với explicit wait, hành vi chờ có thể trở nên khó đoán, vì hai cơ chế cộng dồn lên nhau theo cách không rõ ràng.