تست ایمیل‌های خلاصه‌شده (Digest) در Node.js بدون ایجاد شلوغی در اینباکس

ایمیل‌های خلاصه‌شده (Digest) زمانی مشکل‌ساز می‌شوند که محیط‌های پیش‌نمایش (preview)، خلاصه‌ها را به یک صندوق ورودی (mailbox) مشترک ارسال می‌کنند.

شما دیگر نمی‌توانید تشخیص دهید که هر پیام متعلق به کدام نسخه (build) است. نمی‌توانید بفهمید که آیا لینک لغو اشتراک (unsubscribe) به‌روز است یا خیر. همچنین ممکن است متوجه نشوید که آیا قالب ایمیل با بخش کاربری (user segment) مطابقت دارد یا نه.

من فرآیند تضمین کیفیت (QA) ایمیل‌های خلاصه‌شده را به عنوان یک مسیر محصول در نظر می‌گیرم. اپلیکیشن جاوااسکریپت رویداد را زمان‌بندی می‌کند. Node.js محتوا را رندر می‌کند. و بررسی اینباکس، تجربه نهایی را تأیید می‌کند.

بسیاری از تیم‌ها این اشتباهات را مرتکب می‌شوند:

  • آن‌ها از یک صندوق ورودی برای چندین بار اجرا استفاده می‌کنند. خلاصه روز دوشنبه در کنار نسخه روز سه‌شنبه قرار می‌گیرد.
  • آن‌ها به داده‌های قدیمی محیط استیجینگ (staging) با رشته‌های ایمیل موقت تکیه می‌کنند.
  • آن‌ها HTML رندر شده را به عنوان خط پایان در نظر می‌گیرند. اسنپ‌شات‌های HTML حتی زمانی که داده‌های زنده اشتباه هستند، با موفقیت تأیید می‌شوند.

یک تست خوب باید پیام واقعی که خواننده دریافت می‌کند را اثبات کند. در عوض، از این چرخه ساده استفاده کنید:

  • یک محرک تست (test trigger)، یک خلاصه برای یک بخش کاربری خاص ایجاد می‌کند.
  • Node.js خلاصه را با استفاده از داده‌های واقعی استیجینگ تولید می‌کند.
  • تست برای آن اجرای خاص، از یک اینباکس مجزا استفاده می‌کند.
  • اجراکننده (runner)، خلاصه را باز کرده و بلوک‌های خلاصه را بررسی می‌کند.
  • تست تأیید می‌کند که لینک‌ها به هاست و پارامترهای کمپین صحیح اشاره می‌کنند.

با آدرس‌های ایمیل مانند زیرساخت‌های مصرف‌شدنی (disposable) برخورد کنید. برای هر سناریو، یک حساب ایمیل موقت بسازید. این کار از خراب شدن اجرای بعدی توسط یک کار ناپایدار (flaky job) جلوگیری می‌کند.

یک تست مفید برای ایمیل‌های خلاصه‌شده، این جزئیات را بررسی می‌کند:

  • کار زمان‌بندی شده، یک خلاصه را برای بخش صحیح در صف قرار می‌دهد.
  • خط موضوع (subject line) تاریخ درست را نشان می‌دهد.
  • پیش‌عنوان (preheader) با پرچم‌های ویژگی (feature flags) فعلی مطابقت دارد.
  • لینک‌ها از هاست، تگ‌های UTM و لوکال (locale) صحیح استفاده می‌کنند.
  • لینک‌های لغو اشتراک به محیط صحیح هدایت می‌شوند.
  • هیچ خلاصه تکراری برای یک کاربر واحد ظاهر نمی‌شود.

از اشتراک‌گذاری یک صندوق ورودی بین CI، نسخه‌های پیش‌نمایش و QA دستی خودداری کنید. این کار در ابتدا کارآمد به نظر می‌رسد، اما بعداً باعث ایجاد نتایج مثبت کاذب (false positives) می‌شود.

جداسازی باعث سریع‌تر شدن اصلاحات می‌شود. وقتی یک خلاصه با خطا مواجه می‌شود، می‌دانید که مشکل از زمان‌بند (scheduler)، رندرکننده (renderer) یا خودِ پیام است.

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