Flaky test là loại bug làm người mới dùng AI dễ mệt nhất.

Chạy lần một fail. Agent sửa. Chạy lần hai pass. Agent nói xong. Bạn deploy. Hôm sau fail lại.

Nếu không cẩn thận, agent sẽ học một thói quen xấu: thêm retry, tăng timeout, hoặc bỏ assertion khó chịu để test xanh.

Test xanh không giống root cause đã rõ

Web test thường flaky vì UI hiện theo event bất đồng bộ: dữ liệu load chậm, DOM update sau click, animation chưa xong, selector trỏ nhầm element, network mock lệch, race condition giữa state và render. Một nghiên cứu ICST 2026 về web test flakiness cũng nhấn mạnh nhóm nguyên nhân quanh DOM event và dynamic updates, tới mức họ phải dùng phân tích event sequence kết hợp LLM reasoning để tìm nguyên nhân.

Điểm cần nhớ cho vibe coding: flakiness không phải chỉ là “test tool khó tính”. Nó là tín hiệu rằng app hoặc test chưa mô tả đúng thời điểm behavior trở nên thật.

Retry là thuốc giảm đau, không phải chẩn đoán

Retry có chỗ dùng. Production test suite đôi khi cần retry để giảm noise. Nhưng với app vibe-coded, retry quá sớm thường che lỗi:

  • Button click trước khi data sẵn sàng.
  • Success message hiện rồi biến mất.
  • API error không được render ổn định.
  • Test đi qua vì chờ lâu, không phải vì flow đúng.
  • Assertion bị xóa vì agent muốn build pass.

Nếu agent chỉ thêm waitForTimeout(5000), bạn chưa sửa bug. Bạn vừa mua 5 giây im lặng.

Prompt bắt agent tìm root cause

Khi test flaky, dùng prompt này trước khi cho sửa:

Do not add retries or increase timeouts yet.
Explain the root cause hypothesis for this flaky test.
Identify whether the bug is in the app, selector, async waiting, mock data, network timing, or test assertion.
Show the exact event sequence from user action to expected UI state.
Then propose the smallest fix.

Sau khi sửa:

Run the same test multiple times.
Report whether the fix changed app behavior, test waiting logic, selector strategy, or mock setup.
List any retry or timeout changes separately.

Non-tech vẫn review được

Bạn không cần hiểu hết Playwright để review flakiness. Chỉ cần hỏi ba câu:

  1. Test đang chờ dấu hiệu thật nào trên UI?
  2. Nếu API fail, màn hình có state rõ không?
  3. Agent có xóa assertion nào để làm test pass không?

Câu thứ ba rất quan trọng. AI sửa test rất nhanh, nhưng sửa test không đồng nghĩa sửa app.

Chốt lại

Flaky test là một cuộc điều tra nhỏ, không phải việc bấm retry cho qua.

Với vibe coding, test xanh chỉ có giá trị khi bạn biết vì sao nó xanh. Nếu agent không giải thích được event sequence và root cause, đừng để nó sửa bằng timeout. Tăng timeout có thể hợp lý sau khi đã hiểu vấn đề. Trước đó, nó chỉ là cách làm bảng đèn xanh bớt ồn.

Khi app đã có user thật, một flaky test bị che có thể là bug domain chưa được nhìn thấy.

Tham khảo