Kiểm thử Email mời của React mà không bị xung đột hộp thư
Các môi trường preview thường gặp lỗi khi luồng mời gửi dồn dập vào một hộp thư QA dùng chung.
Một tester mở nhầm link. Một người khác lại lấy một tin nhắn cũ. Cả nhóm tranh cãi xem liệu code React bị lỗi hay backend đã gửi dữ liệu cũ.
Bạn phải coi hộp thư là một phần của sản phẩm. Nếu quy trình onboarding phụ thuộc vào email, các môi trường preview của bạn cần một chiến lược cô lập. Nếu không, vòng lặp phản hồi của bạn sẽ bị chậm lại.
Các lỗi thường gặp trong các nhánh preview:
- Link email trỏ đến một bản deployment cũ.
- Các lệnh gọi API được thử lại tạo ra hai lời mời cho cùng một người dùng.
- UI chấp nhận lời mời nhưng lại hiển thị dữ liệu thành viên cũ.
- Một tester sử dụng token trước khi người khác kịp xác thực nhánh đó.
Các hộp thư dùng chung tạo ra các bài kiểm thử thiếu ổn định (flaky tests) và làm giảm sự tin cậy.
Hãy sử dụng quy trình đơn giản này để khắc phục:
- Tạo lời mời từ màn hình admin React thực tế trong môi trường preview.
- Sử dụng cùng đường dẫn backend, template và logic token giống như môi trường production.
- Điều hướng tin nhắn đến một hộp thư tạm thời chỉ được tạo cho lần chạy đó.
- Mở link trong trình duyệt và kiểm tra trạng thái của ứng dụng.
Các trình tạo email dùng một lần (disposable email generators) hoạt động rất tốt để xác thực nhanh các nhánh. Chúng giúp quy trình của bạn luôn đơn giản.
Một bài kiểm thử preview tốt phải kiểm tra được những điều sau:
- Email chứa đúng host preview cho nhánh đó.
- Chỉ có duy nhất một link mời đang hoạt động cho người nhận.
- Token dẫn đến đúng workspace và vai trò (role).
- Ứng dụng React cập nhật trạng thái truy cập mà không cần tải lại trang thủ công.
- Việc nhấp vào link lần thứ hai sẽ thất bại sau khi đã chấp nhận lời mời.
Đừng quên kiểm chứng ở phía frontend (frontend assertion). Log của backend có thể báo thành công trong khi phía client vẫn hiển thị trạng thái đang chờ (pending). Người dùng sẽ nhận ra điều này ngay lập tức.
Việc thêm một correlation ID từ lúc tạo lời mời đến khi kích hoạt cuối cùng sẽ giúp tiết kiệm thời gian. Nó giúp bạn tìm ra liệu có host nào bị sai trong template do biến môi trường (environment variables) hay không.
Mục tiêu không phải là sử dụng hộp thư dùng một lần ở mọi nơi. Mục tiêu là cô lập luồng mời thực tế. Điều này giúp phát hiện các lỗi hồi quy (regressions) trước khi chúng đến môi trường production.
Hãy sử dụng danh sách kiểm tra này trước khi bạn tin tưởng vào một thay đổi trong luồng mời:
- Email liên kết đến bản deployment preview chính xác.
- Token ánh xạ đúng workspace và vai trò.
- Lần nhấp thứ hai không tái sử dụng cùng một token.
- Trạng thái đã chấp nhận xuất hiện trong UI mà không cần điều hướng thêm.
- Hộp thư dễ dàng nhận diện và loại bỏ.