Review Playwright Test do AI viết: Đừng chỉ nhìn chữ “Pass”!

AI có thể tạo test Playwright rất nhanh, nhưng một test “Pass” chưa chắc đã kiểm tra đúng yêu cầu. Khi review End-to-End (E2E) test do AI viết, hãy tập trung vào các điểm quan trọng sau:

1. Test có đúng yêu cầu nghiệp vụ không?

Chạy và kiểm tra thao tác test từng bước để đảm bảo các bước và kết quả kiểm tra bám sát test case, không bỏ sót luồng quan trọng.

2. Dùng Page Object / Fixture

AI thường có xu hướng viết tất cả mọi thứ gom chung vào trong một hàm test duy nhất:

test(...) {
  // ...
  // ...
  // Viết dài lê thê tới 200 dòng code liên tục
}

Cách tiếp cận chuẩn (Nên dùng):

• Page: orderPage.createOrder()

• Fixture: authenticatedPage

• Test ngắn gọn:

  login
  create order
  verify order success
  

Nguyên tắc phân chia thành phần:

3. Assert có đủ mạnh không?

Tránh các assert quá chung chung như chỉ kiểm tra element hiển thị. Hãy xác nhận đúng kết quả nghiệp vụ mong đợi. Đây là lỗi AI gặp rất nhiều.

     ❌ Assert yếu (Dễ pass giả)

await expect(page.locator('.toast')).toBeVisible();
// Toast thông báo lỗi hay thông báo gì hiển thị lên cũng đều PASS!

• Assert tốt (Khuyến khích)

  // Cách 1: Kiểm tra text hiển thị chính xác
  await expect(page.getByText('Order created successfully')).toBeVisible();
  
  // Cách 2: Kiểm tra URL chuyển hướng đúng
  await expect(page).toHaveURL('/orders/123');
  
  // Cách 3: Kiểm tra API response status
  await expect(response.status()).toBe(200);
  

🔍 Reviewer cần tự hỏi: Assert đã đúng kết quả business mong muốn chưa? Case này có thể bị pass giả (false positive) không?

4. Locator có ổn định không?

Ưu tiên sử dụng data-testid, role, hoặc các locator có ý nghĩa định danh rõ ràng. Tránh dùng CSS Selector phức tạp, XPath quá dài hoặc nth-child dễ gãy khi giao diện thay đổi.

5. Có sử dụng wait hợp lý không?

Tuyệt đối không dùng waitForTimeout() (hard-coded wait). Nên chờ theo trạng thái thực tế của hệ thống như: đợi API response, đợi URL thay đổi hoặc đợi element đích xuất hiện là toBeVisible() hay waitForResponse(...)

6. Có phụ thuộc dữ liệu cứng (Hard-coded Data) không?

AI hay viết sẵn các dữ liệu chết vào code như: test@gmail.com, ORDER-001, Product A.

🔍 Reviewer cần tự hỏi: Data này có tồn tại mãi không? Khi chạy lại test nhiều lần liên tiếp (hoặc chạy song song) thì dữ liệu này có bị trùng và gây fail test không?

7. Log có đủ để debug khi fail không?

Nên yêu cầu AI cấu trúc log ngắn gọn và tường minh theo luồng chạy để dễ tra cứu khi có lỗi:

[START] TC01 Create Order
[STEP1] Login
[STEP2] Create Order
[STEP3] Verify Result
[PASS] TC01

8. Test có độc lập và dữ liệu có thể tái sử dụng không?

Các bài test không được phụ thuộc vào thứ tự chạy (test này chạy trước mới tới test sau) hoặc phụ thuộc vào dữ liệu do một bài test khác sinh ra.

9. Test có đúng phạm vi E2E không?

Các phần về Business logic sâu, validation chi tiết và tính toán phức tạp nên được ưu tiên kiểm tra ở Integration Test (Kiểm thử tích hợp). E2E chỉ nên tập trung vào luồng đi của người dùng (User flow) và kết quả cuối cùng.

📝 Checklist nhanh khi Review

• [ ] Đúng nghiệp vụ: Bám sát yêu cầu, không thiếu luồng.

• [ ] Cấu trúc: Sử dụng Page/Fixture hợp lý, code không bị loãng.

• [ ] Assert: Kiểm tra chuẩn kết quả, không assert chung chung.

• [ ] Locator: Ổn định (ưu tiên data-testid, role).

• [ ] Bất đồng bộ: Không dùng sleep/wait cứng.

• [ ] Dữ liệu: Không hard-code dữ liệu dễ gây xung đột khi chạy lại.

• [ ] Tính độc lập: Test độc lập hoàn toàn, có thể chạy song song.

• [ ] Phạm vi: Tập trung vào luồng người dùng (User flow).

• [ ] Log: Dễ đọc, dễ debug khi có lỗi.

💡 Quy tắc cốt lõi: Khi review E2E do AI viết, hãy ưu tiên kiểm tra đúng yêu cầu, đúng assert và đúng locator. Ba yếu tố này chiếm 80% lỗi thực tế trong các đoạn test Playwright do AI sinh ra và quyết định phần lớn chất lượng của hệ thống Automation Test.