Kiểm thử luồng thay đổi email mà không bị nhầm lẫn liên kết
Việc thay đổi email tài khoản có vẻ là một việc nhỏ. Đây là một cái bẫy phổ biến đối với các đội ngũ QA. Một tester cập nhật địa chỉ. Một người khác lại mở email đó trước. Giờ đây, cả đội sẽ tranh cãi xem liệu trang React có bị lỗi hay liên kết đó thuộc về người dùng khác.
Sự nhầm lẫn này xảy ra khi bạn coi hộp thư đến là một công cụ dùng chung thay vì là một phần của tính năng.
Các hành trình thay đổi email rất mong manh. Chúng làm thay đổi các tài khoản đang hoạt động. Bạn phải làm việc với những người dùng đã xác thực và các trạng thái đang chờ xử lý (pending states).
Các vấn đề phổ biến bao gồm:
- Tin nhắn gửi đến một hộp thư chung mà không có chủ sở hữu rõ ràng.
- Liên kết hoạt động, nhưng giao diện (UI) lại hiển thị dữ liệu cũ.
- Backend đã cập nhật, nhưng cache ở frontend vẫn bị cũ (stale).
- Các tester nhấn vào liên kết dành cho các tester khác.
Để khắc phục điều này, hãy sử dụng một email dùng một lần (burner email) cho mỗi lần chạy thử nghiệm. Đừng sử dụng một bí danh (alias) staging duy nhất.
Hãy làm theo trình tự sau:
- Tạo một người dùng thử nghiệm thông qua ứng dụng.
- Yêu cầu thay đổi email trong phần cài đặt React.
- Gửi email thông qua backend thật.
- Chuyển hướng tin nhắn đến một hộp thư chỉ dùng một lần.
- Mở liên kết và xác minh màn hình cài đặt hiển thị địa chỉ mới.
Sự cô lập giúp xác định rõ quyền sở hữu. Bạn sẽ không cần phải viết những ghi chú lộn xộn trên Slack để nhớ xem mình đã dùng hộp thư nào.
Một quy tắc cho các ứng dụng React: luôn kiểm tra màn hình sau khi đọc dữ liệu mới. Đừng tin tưởng vào trạng thái client lạc quan (optimistic client state). Một mutation có thể trả về kết quả thành công, nhưng việc tải lại trang có thể hiển thị lại giá trị cũ. Điều này xảy ra thường xuyên hơn mọi người vẫn tưởng.
Bài kiểm tra end-to-end của bạn phải xác minh:
- Email được gửi đến địa chỉ mới đang chờ xử lý.
- Liên kết trỏ đến đúng host.
- Liên kết cập nhật bản ghi tài khoản.
- Địa chỉ cũ biến mất sau khi refetch.
- Việc sử dụng lại liên kết phải thất bại một cách an toàn.
Các khẳng định (assertions) ở frontend là phần quan trọng nhất. Một log backend báo thành công là vô nghĩa nếu người dùng vẫn thấy địa chỉ sai. Nếu cache hoặc store của bạn bị cũ, tính năng đó coi như bị lỗi.
Khả năng truy vết (traceability) cũng rất hữu ích. Hãy sử dụng một correlation ID trong log và metadata của email. Điều này giúp kết nối yêu cầu với việc gửi và xác nhận.
Các đánh đổi cần cân nhắc:
- Việc kiểm tra hộp thư (inbox polling) chậm hơn so với việc sử dụng mock.
- Các địa chỉ dùng một lần chỉ được chứa dữ liệu không thuộc môi trường production.
- Các môi trường xem trước (preview environments) cần có các quy tắc dọn dẹp.
Đừng bỏ qua bước này. Các luồng email thường bị lỗi ở những khoảng trống giữa các hệ thống. Đó chính là nơi mà các bản mock yếu nhất.