Flaky test là gì và làm thế nào để xử lý chúng?

Question

Accepted Answer

**Flaky test** là các test **pass hoặc fail không nhất quán** mà không thay đổi code — đôi khi pass, đôi khi fail trên cùng code. Chúng là một vấn đề nghiêm trọng vì xói mòn niềm tin vào test suite. Hiểu nguyên nhân và cách sửa chúng là quan trọng.

## Flaky test là gì và tại sao chúng có hại

```text
Một test FLAKY cho kết quả KHÔNG NHẤT QUÁN (đôi khi pass, đôi khi fail) trên CÙNG code:
  → có hại: XÓI MÒN NIỀM TIN — người ta bắt đầu phớt lờ failure ("à, chỉ flaky thôi") →
    failure thật cũng bị bỏ sót
  → tốn thời gian vào báo động giả / chạy lại; làm hỏng CI; giảm tự tin vào toàn bộ suite
→ Flaky test còn tệ hơn không có test nếu chúng làm người ta mất tin vào tất cả test.
```

## Nguyên nhân phổ biến

```text
✗ TIMING / async → race condition; không chờ đúng cách cho thao tác async (nguyên nhân hàng đầu
  trong test UI/E2E); sleep tùy tiện
✗ PHỤ THUỘC THỨ TỰ → test phụ thuộc nhau / state có thể thay đổi dùng chung
✗ Dependency BÊN NGOÀI → network/service thật (network chập chờn, rate limit, downtime)
✗ KHÔNG DETERMINISTIC → thời gian/ngày, ngẫu nhiên, timezone, locale
✗ MÔI TRƯỜNG test → state còn sót, dữ liệu chưa dọn, vấn đề concurrency/parallel
```

## Sửa và quản lý flaky test

```text
✓ Sửa NGUYÊN NHÂN GỐC: chờ điều kiện (không sleep); làm test ĐỘC LẬP và dọn dẹp
  state; MOCK dependency bên ngoài; kiểm soát thời gian/ngẫu nhiên (inject chúng)
✓ Đảm bảo cô lập đúng (không state dùng chung, không phụ thuộc thứ tự)
✓ Đừng chỉ RETRY mù quáng (nó che giấu vấn đề) — điều tra và sửa
✓ QUARANTINE các test flaky dai dẳng (cô lập để chúng không chặn) TRONG KHI sửa chúng
✓ Coi trọng flakiness — theo dõi và giải quyết (nó làm suy giảm toàn bộ suite)
```

## Tại sao điều này quan trọng

Hiểu flaky test và cách xử lý chúng là quan trọng vì **flaky test là một vấn đề nghiêm trọng, phổ biến làm suy yếu giá trị của toàn bộ một test suite**, nên đây là kiến thức thực hành có giá trị.

Một flaky test (pass hoặc fail không nhất quán trên cùng code) đặc biệt có hại vì nó **xói mòn niềm tin**: khi test fail không đoán trước được, người ta bắt đầu phớt lờ failure ("chỉ flaky thôi"), nghĩa là **failure thật cũng bị bỏ sót** — nên flakiness làm suy giảm sự tự tin vào toàn bộ suite, có khả năng làm nó tệ hơn vô dụng.

Hiểu tác hại này tạo động lực để coi trọng flakiness.

Hiểu **các nguyên nhân phổ biến** — **vấn đề timing/async** (race condition, không chờ đúng cách cho thao tác async, sleep tùy tiện — nguyên nhân hàng đầu đặc biệt trong test UI/E2E), **phụ thuộc thứ tự** (test phụ thuộc nhau hoặc state dùng chung), **dependency bên ngoài** (network/service thật với sự chập chờn và downtime của chúng), **không deterministic** (thời gian, ngẫu nhiên, timezone, locale), và **vấn đề môi trường** (state còn sót, concurrency) — là cần thiết để chẩn đoán flakiness.

Hiểu cách **sửa và quản lý** chúng — sửa nguyên nhân gốc (chờ điều kiện thay vì sleep, làm test độc lập và sạch, mock dependency bên ngoài, kiểm soát thời gian và ngẫu nhiên), đảm bảo cô lập, **không retry mù quáng** (vốn che giấu vấn đề), quarantine các test flaky dai dẳng trong khi sửa chúng, và coi flakiness như một vấn đề nghiêm trọng cần theo dõi và giải quyết — phản ánh cách tiếp cận đúng.

Vì flaky test là một vấn đề phổ biến, nghiêm trọng làm suy yếu niềm tin vào và giá trị của một test suite (một vấn đề thực trong nhiều dự án thực tế), và vì hiểu nguyên nhân và cách xử lý đúng đắn của chúng (sửa nguyên nhân gốc, cô lập, không chỉ retry) là cần thiết để duy trì một test suite đáng tin cậy, hiểu flaky test là kiến thức thực hành có giá trị, quan trọng — giải quyết một vấn đề testing thực tế đáng kể, quan trọng để giữ một test suite tin cậy và được tin tưởng, và phản ánh sự trưởng thành thực tiễn để xử lý một trong những vấn đề gây bực bội và tai hại nhất của testing.