Playwright Agents: Planner · Generator · Healer (viết test AI-native)

1. Vì sao Playwright chuyển sang AI-native test authoring

Trong nhiều năm, viết test E2E là công việc thủ công tốn sức: người kiểm thử phải tự đọc giao diện, tự đặt locator, tự đoán bước, rồi vật lộn với những test giòn (flaky) mỗi khi UI đổi. Từ Playwright 1.56 trở đi, đội Playwright giới thiệu ba tác nhân AI (agent) hợp tác với nhau nhằm dịch chuyển phần lớn công đoạn nháp sang máy, còn con người tập trung vào phán đoán nghiệp vụ. Đây không phải là 'AI thay người kiểm thử', mà là chia lại vai trò: máy làm phần lặp, người giữ oracle và trách nhiệm.

Ba tác nhân đó là Planner (người lập kế hoạch), Generator (người sinh code) và Healer (người chữa test). Chúng nối thành một dây chuyền: Planner khám phá ứng dụng và viết một kế hoạch kiểm thử bằng Markdown; Generator biến kế hoạch thành các file spec chạy được và tự xác minh locator trên app thật; Healer chạy test ở chế độ gỡ lỗi, đọc console/network/snapshot để sửa test hỏng hoặc đánh dấu skip. Điểm mấu chốt là cả ba đều 'grounded' vào ứng dụng thật, không bịa ra bước trong không khí.

Để hiểu vì sao đây là bước ngoặt, hãy nhìn lại nút thắt cũ. Test giòn (flaky) làm mất niềm tin vào bộ test: đội ngũ bắt đầu bỏ qua đèn đỏ vì 'chắc lại flaky thôi', và khi đèn đỏ bị phớt lờ, một lỗi thật lọt qua. Việc bảo trì locator khi UI đổi ngốn thời gian mà không tạo giá trị mới. Ba agent nhắm thẳng vào các nút thắt này: Generator xác minh locator để giảm test đỏ vô cớ, Healer bảo trì locator tự động, còn Planner đảm bảo kế hoạch bám vào ứng dụng thật. Kết quả là con người có thêm thời gian cho phần khó nhất và giá trị nhất: thiết kế oracle và phân tích rủi ro.

2. Khởi tạo: npx playwright init-agents

Lệnh khởi tạo tạo ra bộ khung cho ba agent cùng một file seed.spec.ts chứa fixture và bước chuẩn bị dùng chung. Bạn chọn loại coding agent đang dùng (ví dụ Claude Code, Copilot, Cursor) để Playwright ghi cấu hình phù hợp. Sau khi chạy, dự án có thêm định nghĩa agent, mô tả công cụ mà agent được phép gọi, và một chỗ để bạn khai báo môi trường (baseURL, tài khoản test, dữ liệu seed).

# Cài Playwright mới nhất và khởi tạo agents
npm init playwright@latest
npx playwright install --with-deps chromium

# Sinh khung ba agent + seed.spec.ts
npx playwright init-agents
# ? Which coding agent are you using?  › Claude Code
# ✔ Created  .playwright/agents/planner.md
# ✔ Created  .playwright/agents/generator.md
# ✔ Created  .playwright/agents/healer.md
# ✔ Created  tests/seed.spec.ts

File seed.spec.ts là điểm neo cho toàn bộ agent. Nó khai báo cách đăng nhập, cách nạp dữ liệu sạch, và các fixture mà mọi test sinh ra đều kế thừa. Nếu seed viết tốt, agent không phải lặp lại phần đăng nhập trong từng test và ít bịa dữ liệu hơn. Nếu seed viết ẩu, mọi test sinh ra sẽ thừa hưởng sự mong manh đó.

// tests/seed.spec.ts — fixture & setup dùng chung cho mọi test sinh ra
import { test as base, expect } from '@playwright/test';

export const test = base.extend<{ authedPage: import('@playwright/test').Page }>({
  authedPage: async ({ page }, use) => {
    await page.goto('/login');
    await page.getByLabel('Email').fill(process.env.TEST_USER!);
    await page.getByLabel('Mật khẩu').fill(process.env.TEST_PASS!);
    await page.getByRole('button', { name: 'Đăng nhập' }).click();
    await expect(page.getByRole('heading', { name: 'Bảng điều khiển' })).toBeVisible();
    await use(page); // agent sinh test dùng authedPage, không lặp login
  },
});
export { expect };

3. Planner: khám phá app và viết test plan Markdown

Planner là agent đầu tiên chạy. Nó điều hướng qua ứng dụng thật, quan sát các màn hình, các luồng, các nút và trường nhập, rồi đề xuất một kế hoạch kiểm thử dưới dạng Markdown có cấu trúc: mục tiêu, tiền điều kiện, các kịch bản happy path và các nhánh lỗi. Vì Planner đọc cây accessibility và DOM thật, kế hoạch của nó bám vào giao diện đang tồn tại chứ không phải trí tưởng tượng.

<!-- specs/checkout.plan.md — do Planner sinh, người review trước khi generate -->
# Test Plan: Thanh toán giỏ hàng (Checkout)

## Tiền điều kiện
- Người dùng đã đăng nhập (fixture authedPage)
- Giỏ có 2 sản phẩm, tồn kho > 0

## Kịch bản
1. Happy path: thanh toán thẻ hợp lệ → đơn "PAID", tồn kho giảm đúng số lượng
2. Thẻ bị từ chối → hiện lỗi, đơn KHÔNG tạo, tồn kho KHÔNG đổi
3. Hết hàng giữa chừng → chặn đặt, thông báo "Out of stock"
4. Bấm "Đặt hàng" hai lần (double submit) → chỉ 1 đơn được tạo (idempotency)

## Oracle (bất biến nghiệp vụ)
- Tồn kho không bao giờ âm
- Số tiền trừ = tổng đơn (không lệch)
- Retry mạng → đúng 1 đơn cuối cùng

Điểm quan trọng: kế hoạch này là văn bản người đọc được. Đó là nơi bạn — người kiểm thử có kinh nghiệm — chèn oracle nghiệp vụ mà AI khó tự biết: tồn kho không âm, tiền được bảo toàn, double-submit chỉ tạo một đơn. Bạn sửa Markdown, thêm case biên, xoá case vô nghĩa. Chỉ khi kế hoạch được duyệt, bạn mới cho Generator biến nó thành code.