Bạn push một thay đổi CSS đúng một dòng, và một cái nút ở tận trang khác lặng lẽ vỡ tan. Không test nào fail, code review cũng không bắt được, và một tuần sau bạn nghe tin từ người dùng. Team nhỏ nào cũng từng gặp con bug này.
Câu trả lời theo sách giáo khoa là viết thêm unit test. Tôi đang quản lý một team dev nhỏ, và nói thật, viết unit test cho từng component và từng trạng thái layout là thứ xa xỉ mà chúng tôi không có. Thứ chúng tôi dựa vào là visual testing: chụp màn hình các trang, so với những bản baseline đã biết là đúng, rồi đánh dấu bản build nếu có pixel nào xê dịch mà lẽ ra không được xê dịch. Xét công sức bỏ ra, chưa có cách nào tôi từng thử mà theo kịp.
Vì sao ảnh chụp màn hình đáng đồng tiền bát gạo#
Cái hay nằm ở những thứ bạn không phải viết. Visual test không kiểm tra từng phần tử riêng lẻ; nó nhìn cả trang như một tổng thể. Layout bị xô lệch, màu sắc thay đổi, responsive bị vỡ, các phần tử đè lên nhau — đúng những thứ hay lọt qua code review và viết unit test để bao phủ thì cực kỳ khổ sở — tất cả đều hiện ra thành một bản diff ngay trong PR.
Chi phí bảo trì cũng gần như bằng không. Bạn đặt baseline một lần, rồi nó chạy trên mọi PR và lần nào cũng cho cùng một kết quả. UI thay đổi có chủ đích? Cập nhật baseline rồi làm tiếp. Thay đổi ngoài ý muốn? Bản diff nằm sẵn trong PR, chẳng ai phải click lòng vòng nửa cái trang web để tìm ra nó.
Nó không thay thế unit test#
Unit test kiểm tra logic; ảnh chụp màn hình kiểm tra giao diện. Về lâu dài bạn sẽ cần cả hai. Nhưng nếu team bạn nhỏ và phải chọn chỗ để bỏ những giờ đầu tiên vào, visual test cho bạn nhiều độ bao phủ trên mỗi giờ thiết lập hơn bất cứ thứ gì khác. Nguyên tắc của tôi: unit test cho phần business logic mà hỏng thì đau thật sự, visual test cho phần còn lại.
Toàn bộ hệ thống chỉ có vậy — baseline, diff trên mỗi PR, và thỉnh thoảng một cú click “ừ, cái đó là cố ý”. Nó bắt được nhiều lỗi hơn hẳn những gì bạn dám kỳ vọng.
Thêm thông tin và link hữu ích#
Visual testing với Playwright#
Tài liệu về snapshot testing của Playwright: chụp cả trang hoặc từng phần tử, so với baseline, và quản lý việc cập nhật baseline khi UI được thay đổi có chủ đích. Visual testing với Playwright
Best practice khi test với Playwright#
Lời khuyên của Playwright cho các test có đụng tới database: tách biệt dữ liệu test, dọn dẹp sau khi chạy, và giữ các test độc lập với nhau để cả bộ test luôn đáng tin cậy. Best practice khi test với Playwright