1. Tóm tắt nhanh & màn hình bạn sẽ test
Chào bạn mới! Nếu bạn từng viết test tự động chỉ kiểm tra 'bấm nút có hoạt động không', 'dữ liệu có đúng không', bạn sẽ ngạc nhiên khi biết rằng một trang có THỂ pass toàn bộ test chức năng nhưng giao diện vẫn... vỡ: nút bị lệch vị trí, banner sai màu thương hiệu, chữ bị tràn ra ngoài khung. Đó là vì test chức năng không 'nhìn' vào giao diện — nó chỉ kiểm tra hành vi và dữ liệu. Visual testing sinh ra để lấp đúng khoảng trống này: chụp ảnh màn hình thật, so sánh với ảnh chuẩn đã được duyệt, và báo lỗi nếu có khác biệt đáng kể. Chúng ta sẽ học qua trang sản phẩm thật của ShopEasy, có hình minh hoạ và code Playwright chạy được.
2. Vấn đề: test chức năng pass nhưng giao diện vỡ
Đội automation của ShopEasy có bộ test chức năng khá đầy đủ cho trang sản phẩm: bấm 'Mua ngay' có chuyển tới giỏ hàng không, giá hiển thị có đúng với dữ liệu backend không, nút có disable đúng lúc hết hàng không. Toàn bộ các test này chạy xanh mỗi ngày trên CI. Nhưng một buổi sáng, bộ phận chăm sóc khách hàng nhận được phản ánh: nút 'Mua ngay' trên trang sản phẩm bỗng đổi màu tím kỳ lạ, khó nhìn thấy trên nền sáng, và bị đẩy lệch sang phải so với thiết kế gốc.
Vấn đề là: KHÔNG một test chức năng nào trong bộ trên phát hiện ra chuyện này, vì câu assert của chúng chỉ kiểm tra thuộc tính DOM, URL sau khi click, hay text hiển thị — hoàn toàn không kiểm tra màu sắc CSS thực tế hay toạ độ pixel trên màn hình. Nút vẫn có đúng id, vẫn dẫn đúng tới trang giỏ hàng, dữ liệu vẫn khớp — nên mọi assert vẫn pass. Đây gọi là 'false negative' của test chức năng: test báo ổn trong khi thực tế người dùng đang gặp trải nghiệm tệ.
3. Visual testing là gì & cách hoạt động: Baseline, Actual, Diff
Visual testing hoạt động dựa trên 3 ảnh. Ảnh 'baseline' là ảnh chuẩn, đã được con người xem qua và xác nhận là đúng thiết kế, thường được lưu ngay trong repo dưới một thư mục -snapshots đi kèm mã nguồn. Ảnh 'actual' là ảnh được chụp mới mỗi lần chạy test, phản ánh đúng giao diện thật tại thời điểm đó. Khi so sánh hai ảnh này theo từng pixel, công cụ sẽ tự sinh ra ảnh 'diff' — highlight rõ những vùng khác biệt bằng màu nổi bật (thường là đỏ hoặc hồng) để người xem nhận ra ngay chỗ nào đã đổi.
Với Playwright, lần đầu tiên bạn chạy expect(page).toHaveScreenshot() cho một trang chưa từng có ảnh baseline, Playwright sẽ tự động CHỤP và LƯU ảnh đó làm baseline, đồng thời báo cho bạn biết là đã tạo mới (không phải test fail thật). Từ lần chạy thứ hai trở đi, ảnh actual mới chụp sẽ được so với baseline đã lưu trước đó; nếu tỉ lệ pixel khác nhau vượt quá ngưỡng cho phép, test sẽ fail và Playwright đính kèm cả 3 ảnh — baseline, actual, diff — trong báo cáo HTML để bạn đối chiếu trực quan.
4. Viết test toHaveScreenshot đầu tiên (thực hành)
Giờ ta viết test visual đầu tiên cho trang sản phẩm ShopEasy. Làm theo thứ tự dưới đây để có một test toHaveScreenshot chạy được ngay.
▶ Bước 1: Tạo thư mục tests/visual/ và file product-page.spec.js bên trong.
▶ Bước 2: Import test, expect từ @playwright/test ở đầu file.
▶ Bước 3: Trong test, goto trang sản phẩm ShopEasy rồi gọi expect(page).toHaveScreenshot('ten-anh.png').
💬 Bình luận (0)
Chưa có bình luận nào. Hãy là người đầu tiên!