جریانهای تغییر ایمیل را بدون از دست دادن لینکها تست کنید
تغییر ایمیل حساب کاربری کار کوچکی به نظر میرسد، اما یک تله رایج برای تیمهای QA است. یک تستکننده آدرسی را بهروزرسانی میکند و شخص دیگری زودتر ایمیل را باز میکند. حالا تیم بر سر اینکه آیا صفحه React خراب است یا لینک متعلق به کاربر اشتباهی بوده، با هم بحث میکنند.
این سردرگمی زمانی رخ میدهد که با اینباکس (inbox) به عنوان یک ابزار مشترک برخورد میکنید، نه به عنوان بخشی از قابلیت (feature).
مسیرهای تغییر ایمیل شکننده هستند. آنها حسابهای فعال را تغییر میدهند. شما با کاربران احراز هویت شده و حالتهای در انتظار (pending states) سروکار دارید.
مشکلات رایج عبارتند از:
- پیامها در یک اینباکس مشترک بدون مالک مشخص میرسند.
- لینک کار میکند، اما رابط کاربری (UI) دادههای قدیمی را نشان میدهد.
- بکاند (backend) بهروز میشود، اما کش فرانتاند (frontend cache) قدیمی باقی میماند.
- تستکنندهها روی لینکهایی کلیک میکنند که برای تستکنندههای دیگر بوده است.
برای رفع این مشکل، برای هر بار اجرای تست از یک ایمیل موقت (burner email) استفاده کنید. از یک نام مستعار (alias) استیجینگ واحد استفاده نکنید.
این توالی را دنبال کنید:
- یک کاربر تست از طریق اپلیکیشن ایجاد کنید.
- درخواست تغییر ایمیل را در تنظیمات React ارسال کنید.
- ایمیل را از طریق بکاند واقعی ارسال کنید.
- پیام را به یک اینباکس یکبارمصرف هدایت کنید.
- لینک را باز کنید و تأیید کنید که صفحه تنظیمات، آدرس جدید را نشان میدهد.
جداسازی باعث شفافیت مالکیت میشود. دیگر نیازی به یادداشتهای نامنظم در Slack نخواهید داشت تا به یاد بیاورید از کدام اینباکس استفاده کردهاید.
قانون برای اپلیکیشنهای React: همیشه صفحه را پس از خواندن دادههای تازه بررسی کنید. به حالت خوشبینانه کلاینت (optimistic client state) اعتماد نکنید. ممکن است عملیات تغییر (mutation) با موفقیت انجام شود، اما بارگذاری مجدد صفحه (page reload) مقدار قدیمی را برگرداند. این اتفاق بیش از آنچه مردم اعتراف میکنند، رخ میدهد.
تست end-to-end شما باید موارد زیر را تأیید کند:
- ایمیل به آدرس جدید در حالت انتظار ارسال میشود.
- لینک به هاست (host) صحیح اشاره میکند.
- لینک رکورد حساب کاربری را بهروز میکند.
- آدرس قدیمی پس از بازخوانی دادهها (refetch) ناپدید میشود.
- استفاده مجدد از لینک با شکست ایمن مواجه میشود.
تأییدیه های فرانتاند (Frontend assertions) مهمترین بخش هستند. اگر کاربر آدرس اشتباه را ببیند، لاگ بکاند که پیام موفقیت میدهد بیفایده است. اگر کش یا استور (store) شما قدیمی باشد، آن قابلیت خراب است.
قابلیت ردیابی (Traceability) نیز کمک میکند. از یک شناسه همبستگی (correlation ID) در لاگها و متادیتای ایمیل خود استفاده کنید. این کار درخواست را به تحویل و تأیید متصل میکند.
مواردی که باید در نظر بگیرید:
- بررسی مداوم اینباکس (Inbox polling) کندتر از استفاده از موکها (mocks) است.
- آدرسهای یکبارمصرف باید فقط حاوی دادههای غیرتولیدی (non-production) باشند.
- محیطهای پیشنمایش (Preview environments) به قوانین پاکسازی نیاز دارند.
این مرحله را نادیده نگیرید. جریانهای ایمیل در شکافهای بین سیستمها دچار مشکل میشوند. این دقیقاً همان جایی است که موکها (mocks) در ضعیفترین حالت خود هستند.