Kiểm thử luồng thay đổi email trong React mà không bị nhầm lẫn các liên kết
Thay đổi email tài khoản có vẻ là một việc nhỏ. Nhưng thực tế, nó lại là một nguồn gây ra lỗi kiểm thử lớn.
Người kiểm thử thường nhầm lẫn các liên kết xác nhận. Một người cập nhật địa chỉ trong khi người khác lại mở tin nhắn trước. Điều này gây ra sự bối rối. Nhóm bắt đầu tranh luận xem trang React bị lỗi hay liên kết đó thuộc về người dùng khác.
Vấn đề này xảy ra vì các nhóm coi hộp thư đến là một công cụ dùng chung. Bạn phải coi hộp thư đến là một phần của hợp đồng tính năng (feature contract).
Các hành trình thay đổi email rất mong manh. Chúng thay đổi một tài khoản đang hoạt động. Người dùng đã đăng nhập. Thường có một cuộc chạy đua giữa trạng thái email đang chờ (pending) và email đã xác nhận (confirmed).
Các vấn đề phổ biến bao gồm:
- Tin nhắn xác nhận gửi đến một hộp thư chung mà không có cách nào để theo dõi chúng.
- UI hiển thị dữ liệu cũ ngay cả khi liên kết đã xác nhận yêu cầu mới.
- Backend cập nhật, nhưng cache của frontend vẫn hiển thị địa chỉ cũ.
- Một người kiểm thử nhấn vào liên kết dành cho người khác.
Một hộp thư dùng chung khiến việc tìm nguyên nhân lỗi trở nên khó khăn. Hãy sử dụng một địa chỉ email phụ (burner email) duy nhất cho mỗi lần chạy kiểm thử thay vì dùng một bí danh (alias) staging duy nhất.
Hãy tuân theo trình tự chuẩn sau:
- Tạo một người dùng kiểm thử.
- Yêu cầu thay đổi email trong màn hình cài đặt React.
- Gửi email thông qua luồng backend thực tế.
- Điều hướng tin nhắn đến một hộp thư chỉ thuộc về lần kiểm thử này.
- Mở liên kết và xác minh màn hình cài đặt được làm mới với địa chỉ mới.
Điều này giúp phân định quyền sở hữu rõ ràng. Bạn sẽ biết liên kết nào đến từ người dùng nào.
Đối với các ứng dụng React, hãy tuân theo một quy tắc bổ sung. Chỉ thực hiện khẳng định (assert) màn hình sau khi đã đọc dữ liệu mới nhất. Đừ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ể mang lại giá trị cũ nếu backend chưa hoàn tất việc thay đổi.
Một bài kiểm thử end-to-end tốt phải xác minh các điểm sau:
- Email được gửi đến địa chỉ đang chờ chứ không phải địa chỉ cũ.
- Liên kết trỏ đến host của môi trường chính xác.
- 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 cùng một liên kết sẽ thất bại một cách an toàn.
Nếu cache của React query hoặc client store của bạn bị cũ (stale), tính năng sẽ có cảm giác như bị lỗi. Khách hàng chỉ quan tâm liệu màn hình cài đặt có hiển thị đúng thực tế hay không.
Bạn cũng nên thêm một correlation ID vào mỗi yêu cầu. Điều này giúp bạn truy vết một yêu cầu từ người dùng đến việc gửi tin nhắn và xác nhận cuối cùng.
Các hộp thư riêng biệt không thay thế được unit test. Hãy dùng unit test để kiểm tra việc xác thực form và các lỗi API. Hãy dùng luồng hộp thư để chứng minh rằng hành trình thực tế của khách hàng hoạt động trên tất cả các hệ thống.
Trước khi triển khai các thay đổi đối với cài đặt tài khoản, hãy kiểm tra các mục sau:
- Yêu cầu thay đổi từ giao diện React thực tế.
- Xác nhận tin nhắn đến đúng hộp thư dành riêng cho lần chạy đó.
- Xác minh địa chỉ mới hiển thị sau khi refetch.
- Đảm bảo liên kết cũ không thể được sử dụng lại.
- Xác nhận nhật ký kiểm tra (audit logs) hiển thị ai là người đã bắt đầu thay đổi.
Điều này ngăn chặn các lỗi mà mọi thứ trông có vẻ ổn khi kiểm tra riêng lẻ nhưng lại thất bại trong thế giới thực.