Assertion & kiểm chứng kết quả trong automation cho người mới (có code chạy được)

1. Tóm tắt nhanh & màn hình bạn sẽ kiểm chứng

Chào bạn mới! Khi bắt đầu học automation, phần lớn thời gian bạn sẽ tập trung vào việc điều khiển trình duyệt: mở trang, điền form, bấm nút. Nhưng có một sự thật ít ai nhắc tới ngay từ đầu: điều khiển trình duyệt thành công KHÔNG đồng nghĩa với việc tính năng đang hoạt động đúng. Chỉ khi bạn viết ra một câu lệnh so sánh — 'giá trị này PHẢI bằng giá trị kia' — thì test mới thật sự trở thành một phép kiểm chứng. Câu lệnh đó gọi là assertion. Chúng ta sẽ học qua màn kết quả đặt hàng thật của ShopEasy, có hình minh hoạ và code Playwright chạy được.

2. Vấn đề: điều khiển trình duyệt thành công chưa phải kiểm chứng

Hãy hình dung một script tự động: mở trang ShopEasy, thêm 1 sản phẩm vào giỏ, tăng số lượng lên 2, rồi kết thúc. Nếu không có bất kỳ câu expect() nào, script này sẽ 'chạy thành công' về mặt kỹ thuật — trình duyệt không báo lỗi, không phần tử nào bị thiếu. Nhưng nó KHÔNG hề trả lời câu hỏi quan trọng nhất: tổng tiền sau khi tăng số lượng có đúng không? Đây chính là khoảng trống mà nhiều người mới bỏ qua khi mới học automation.

Điều nguy hiểm hơn cả là test 'luôn xanh' này vẫn xuất hiện trong báo cáo CI với dấu tick màu xanh, y hệt các test đang kiểm chứng thật sự. Đội ngũ nhìn vào bảng kết quả sẽ tin rằng tính năng giỏ hàng đang hoạt động tốt — trong khi thực tế không ai kiểm tra điều đó cả. Sự an toàn này là GIẢ, và nó chỉ lộ ra khi khách hàng thật gặp lỗi trên production.

3. Kiểm chứng đúng điều quan trọng: không thừa, không thiếu

Nguyên tắc cốt lõi khi viết assertion là chọn ĐÚNG điều cần kiểm chứng cho mục đích của test đó — không thiếu (bỏ sót điểm quan trọng, dẫn tới test 'luôn xanh' một phần) và không thừa (assert cả những chi tiết không liên quan, khiến test dễ vỡ vô cớ). Với màn kết quả đặt hàng ShopEasy, điều 'quan trọng' là: mã đơn hàng đúng định dạng, trạng thái là 'Đã xác nhận', và tổng tiền khớp với giỏ hàng trước đó.

Assert 'thừa' thường gặp nhất ở người mới là kiểm chứng luôn cả những nội dung hay thay đổi vì lý do không liên quan tới logic — ví dụ banner khuyến mãi, ngày giờ hiển thị, hay id nội bộ không ảnh hưởng nghiệp vụ. Mỗi lần nội dung đó đổi (dù tính năng vẫn đúng), test lại báo FAIL, khiến đội ngũ mất niềm tin và dần bỏ qua các cảnh báo đỏ — kể cả khi có bug thật.

4. Hard assertion vs soft assertion

Có 2 cách assertion xử lý khi thất bại. Hard assertion (assert cứng) — cách mặc định của expect() trong Playwright — sẽ DỪNG test ngay lập tức khi kiểm chứng đầu tiên không khớp; các bước sau đó không chạy nữa. Soft assertion (assert mềm) ghi nhận thất bại nhưng vẫn cho phép test chạy tiếp để kiểm tra các điều kiện còn lại, rồi báo cáo TOÀN BỘ lỗi tìm được cùng lúc khi test kết thúc.

// hard assertion (mac dinh cua Playwright): dung ngay khi that bai
await expect(page.locator('#order-status')).toHaveText('Da xac nhan');
// neu dong tren FAIL, dong duoi se KHONG chay:
await expect(page.locator('#order-total')).toHaveText('398.000d');

// soft assertion: ghi nhan loi nhung van chay tiep, gom het loi cuoi test
await expect.soft(page.locator('#order-status')).toHaveText('Da xac nhan');
await expect.soft(page.locator('#order-total')).toHaveText('398.000d');
await expect.soft(page.locator('#order-id')).toHaveText(/^#SE-\d+$/);
// Playwright se bao ca 3 loi (neu co) cung luc khi test ket thuc

Chọn hard assertion khi bước kiểm chứng sau THẬT SỰ phụ thuộc vào bước trước còn đúng — ví dụ nếu chưa xác nhận trang đã tải đúng, kiểm tra tiếp các phần tử bên trong là vô nghĩa. Chọn soft assertion khi bạn muốn thấy TOÀN CẢNH các sai lệch trên cùng một màn hình trong 1 lần chạy, thay vì phải sửa từng lỗi rồi chạy lại nhiều lần mới thấy lỗi tiếp theo.