Bạn đẩy lên một thay đổi CSS chỉ có đúng một dòng, thế rồi một cái nút ở tận trang khác lặng lẽ vỡ giao diện. Không bài kiểm thử nào báo lỗi, khâu rà soát mã (code review) cũng không phát hiện ra, và một tuần sau bạn mới biết chuyện qua phản hồi của người dùng. Đội nhỏ nào cũng từng dính phải lỗi kiểu này.
Theo sách vở thì câu trả lời là viết thêm kiểm thử đơn vị (unit test). Tôi đang quản lý một đội lập trình nhỏ, và nói thật là viết kiểm thử đơn vị cho từng thành phần (component) và từng trạng thái bố cục là thứ xa xỉ mà chúng tôi không kham nổi. Thay vào đó, chúng tôi dựa vào kiểm thử trực quan (visual testing): chụp màn hình các trang, so với những ảnh chuẩn (baseline) đã biết chắc là đúng, rồi đánh dấu bản dựng nếu có pixel nào xê dịch ở chỗ lẽ ra không được xê dịch. Xét trên công sức bỏ ra, tôi chưa thử cách nào khác mà hiệu quả được như vậy.
Vì sao ảnh chụp màn hình đáng đồng tiền bát gạo#
Cái hay nằm ở chỗ có rất nhiều thứ bạn không cần phải viết. Bài kiểm thử trực quan không kiểm tra từng phần tử riêng lẻ mà đánh giá cả trang như một tổng thể. Bố cục bị xô lệch, màu sắc bị đổi, giao diện bị vỡ trên màn hình có kích thước khác, các phần tử đè lên nhau: đó chính là những lỗi hay lọt qua khâu rà soát mã, mà viết kiểm thử đơn vị để bao phủ thì cực kỳ khổ sở. Với kiểm thử trực quan, tất cả đều hiện ra thành một bản so sánh khác biệt (diff) ngay trong pull request (PR).
Chi phí bảo trì cũng gần như bằng không. Bạn chỉ cần đặt ảnh chuẩn một lần, sau đó bài kiểm thử chạy trên mọi PR và lần nào cũng cho ra cùng một kết quả. Giao diện thay đổi có chủ đích? Cập nhật ảnh chuẩn rồi làm tiếp. Thay đổi ngoài ý muốn? Bản so sánh đã nằm sẵn trong PR, không ai phải bấm lòng vòng qua nửa trang web mới tìm ra.
Kiểm thử trực quan không thay thế kiểm thử đơn vị#
Kiểm thử đơn vị kiểm tra logic, còn ảnh chụp màn hình kiểm tra giao diện. Về lâu dài thì bạn sẽ cần cả hai. Nhưng nếu đội bạn nhỏ và phải chọn nơi để dồn những giờ làm việc đầu tiên, thì tính trên mỗi giờ thiết lập, kiểm thử trực quan cho độ bao phủ nhiều hơn bất cứ thứ gì khác. Nguyên tắc của tôi là: kiểm thử đơn vị dành cho phần logic nghiệp vụ (business logic) mà nếu hỏng thì hậu quả thật sự nghiêm trọng, còn lại cứ để kiểm thử trực quan lo.
Toàn bộ hệ thống chỉ có vậy: ảnh chuẩn, bản so sánh trên mỗi PR, và thỉnh thoảng bấm xác nhận “ừ, chỗ đó là cố ý”. Vậy mà số lỗi nó bắt được nhiều hơn hẳn những gì tôi dám kỳ vọng.
Thông tin thêm và các liên kết hữu ích#
Kiểm thử trực quan với Playwright#
Tài liệu về kiểm thử bằng ảnh chụp (snapshot testing) của Playwright: cách chụp cả trang hoặc từng phần tử, so sánh với ảnh chuẩn, và cập nhật ảnh chuẩn khi giao diện được thay đổi có chủ đích. Kiểm thử trực quan với Playwright
Các thực hành tốt khi kiểm thử với Playwright#
Lời khuyên của Playwright cho các bài kiểm thử có đụng tới cơ sở dữ liệu: tách riêng dữ liệu kiểm thử, dọn dẹp sau khi chạy xong, và giữ các bài kiểm thử độc lập với nhau để cả bộ kiểm thử luôn đáng tin cậy. Các thực hành tốt khi kiểm thử với Playwright