Kiểm thử Email Digest trong Node.js mà không gây nhiễu hộp thư đến

Email digest gây ra nhiều vấn đề khi các môi trường preview gửi các bản tóm tắt đến cùng một hộp thư dùng chung.

Bạn sẽ mất dấu không biết tin nhắn nào thuộc về bản build nào. Bạn không thể biết liệu liên kết hủy đăng ký (unsubscribe) có còn hiệu lực hay không. Bạn cũng có thể bỏ lỡ việc kiểm tra xem template có khớp với phân khúc người dùng hay không.

Tôi coi việc QA email digest như một luồng sản phẩm (product path). Ứng dụng JavaScript lập lịch cho sự kiện. Node.js render nội dung. Việc kiểm tra hộp thư đến sẽ xác nhận trải nghiệm cuối cùng.

Nhiều đội ngũ thường mắc phải những sai lầm sau:

  • Họ tái sử dụng một hộp thư cho nhiều lần chạy. Bản digest của thứ Hai nằm ngay cạnh bản build của thứ Ba.
  • Họ dựa vào dữ liệu staging cũ với các chuỗi email tạm thời.
  • Họ coi HTML đã render là đích đến cuối cùng. Các bản chụp (snapshot) HTML có thể vượt qua bài kiểm tra ngay cả khi dữ liệu thực tế bị sai.

Một bài kiểm tra tốt phải chứng minh được thông điệp thực tế mà người đọc nhận được. Thay vào đó, hãy sử dụng vòng lặp đơn giản này:

  • Một trigger kiểm thử tạo ra một bản digest cho một phân khúc người dùng cụ thể.
  • Node.js tạo bản digest bằng cách sử dụng dữ liệu staging thực tế.
  • Bài kiểm tra sử dụng một hộp thư cô lập cho lần chạy cụ thể đó.
  • Trình chạy (runner) mở bản digest và kiểm tra các khối tóm tắt.
  • Bài kiểm tra xác minh các liên kết trỏ đến đúng host và các tham số chiến dịch (campaign parameters).

Hãy coi các địa chỉ email như một hạ tầng có thể dùng một lần (disposable infrastructure). Tạo một tài khoản email tạm thời cho mỗi kịch bản. Điều này giúp ngăn chặn một job không ổn định (flaky job) làm hỏng các job tiếp theo.

Một bài kiểm tra digest hữu ích cần kiểm tra các chi tiết sau:

  • Job đã lập lịch đưa một bản digest vào hàng đợi cho đúng phân khúc.
  • Dòng tiêu đề hiển thị đúng ngày tháng.
  • Preheader khớp với các feature flag hiện tại.
  • Các liên kết sử dụng đúng host, thẻ UTM và locale.
  • Các liên kết hủy đăng ký dẫn đến đúng môi trường.
  • Không có bản digest trùng lặp nào xuất hiện cho cùng một người dùng.

Đừng dùng chung một hộp thư cho CI, các bản preview build và QA thủ công. Ban đầu nó có vẻ hiệu quả, nhưng về sau nó sẽ tạo ra các kết quả dương tính giả (false positives).

Sự cô lập giúp việc sửa lỗi nhanh hơn. Khi một bản digest thất bại, bạn sẽ biết vấn đề nằm ở bộ lập lịch (scheduler), bộ render, hay chính nội dung tin nhắn.

Nguồn: https://dev.to/ryanlee91/how-i-test-nodejs-digest-emails-without-shared-inbox-noise-54fh