লিঙ্ক মিস না করে ইমেল পরিবর্তনের ফ্লো পরীক্ষা করুন
অ্যাকাউন্টের ইমেল পরিবর্তন করা বিষয়টি ছোট মনে হতে পারে। এটি QA টিমের জন্য একটি সাধারণ ফাঁদ। একজন টেস্টার একটি ঠিকানা আপডেট করেন। অন্য একজন ব্যক্তি ইমেলটি আগে খুলে ফেলেন। এখন টিম নিয়ে বিতর্ক শুরু হয় যে React পেজটি কি কাজ করছে না, নাকি লিঙ্কটি ভুল ইউজারের ছিল।
এই বিভ্রান্তি তখনই ঘটে যখন আপনি ইনবক্সকে ফিচারের অংশ হিসেবে না দেখে একটি শেয়ারড টুল (shared tool) হিসেবে বিবেচনা করেন।
ইমেল পরিবর্তনের প্রক্রিয়াগুলো বেশ নাজুক। এগুলো সক্রিয় অ্যাকাউন্ট পরিবর্তন করে। আপনাকে অথেনটিকেটেড ইউজার (authenticated users) এবং পেন্ডিং স্টেট (pending states) নিয়ে কাজ করতে হয়।
সাধারণ সমস্যাগুলোর মধ্যে রয়েছে:
- কোনো নির্দিষ্ট মালিক ছাড়াই মেসেজগুলো একটি শেয়ারড ইনবক্সে আসে।
- লিঙ্কটি কাজ করে, কিন্তু UI পুরনো ডেটা দেখায়।
- Backend আপডেট হয়, কিন্তু Frontend ক্যাশ (cache) পুরনোই থেকে যায়।
- টেস্টাররা অন্য টেস্টারের জন্য নির্ধারিত লিঙ্কে ক্লিক করেন।
এটি সমাধান করতে, প্রতিটি টেস্ট রানের জন্য একটি বার্নার ইমেল (burner email) ব্যবহার করুন। একটি মাত্র স্টেজিং অ্যালিয়াস (staging alias) ব্যবহার করবেন না।
এই সিকোয়েন্সটি অনুসরণ করুন:
- অ্যাপের মাধ্যমে একটি টেস্ট ইউজার তৈরি করুন।
- React সেটিংসে ইমেল পরিবর্তনের অনুরোধ পাঠান।
- রিয়েল ব্যাকএন্ডের মাধ্যমে মেইলটি পাঠান।
- মেসেজটি একটি ওয়ান-রান (one-run) ইনবক্সে পাঠান।
- লিঙ্কটি খুলুন এবং সেটিংস স্ক্রিনে নতুন ঠিকানা দেখাচ্ছে কি না তা যাচাই করুন।
আইসোলেশন (Isolation) মালিকানা পরিষ্কার রাখে। কোন ইনবক্স ব্যবহার করেছিলেন তা মনে রাখার জন্য আপনাকে Slack-এ অগোছালো নোট রাখার প্রয়োজন হবে না।
React অ্যাপের জন্য একটি নিয়ম: সবসময় নতুন ডেটা রিড করার পর স্ক্রিনটি চেক করুন। Optimistic client state-এর ওপর ভরসা করবেন না। Mutation সফল হতে পারে, কিন্তু পেজ রিলোড করলে পুরনো ভ্যালু আবার ফিরে আসতে পারে। এটি মানুষের ধারণার চেয়েও বেশি ঘটে।
আপনার এন্ড-টু-এন্ড (end-to-end) টেস্ট অবশ্যই যাচাই করতে হবে:
- ইমেলটি নতুন পেন্ডিং ঠিকানায় যাচ্ছে কি না।
- লিঙ্কটি সঠিক হোস্টকে নির্দেশ করছে কি না।
- লিঙ্কটি অ্যাকাউন্ট রেকর্ড আপডেট করছে কি না।
- রিফেচ (refetch)-এর পরে পুরনো ঠিকানাটি মুছে যাচ্ছে কি না।
- লিঙ্কটি পুনরায় ব্যবহার করলে তা নিরাপদে ব্যর্থ হচ্ছে কি না।
ফ্রন্টএন্ড অ্যাসারশন (Frontend assertions) হলো সবচেয়ে গুরুত্বপূর্ণ অংশ। ব্যাকএন্ড লগ যদি 'success' দেখায় কিন্তু ইউজার ভুল ঠিকানা দেখেন, তবে তা কোনো কাজের নয়। যদি আপনার ক্যাশ (cache) বা স্টোর (store) পুরনো থাকে, তবে ফিচারটি ত্রুটিপূর্ণ।
ট্রেসেবিলিটি (Traceability) বা অনুসরণযোগ্যতাও সাহায্য করে। আপনার লগ এবং ইমেল মেটাডেটাতে একটি কোরিলেশন আইডি (correlation ID) ব্যবহার করুন। এটি রিকোয়েস্টকে ডেলিভারি এবং কনফার্মেশনের সাথে সংযুক্ত করে।
বিবেচ্য বিষয়সমূহ (Tradeoffs):
- ইনবক্স পোলিং (Inbox polling) মক (mocks)-এর চেয়ে ধীরগতির।
- ডিসপোজেবল অ্যাড্রেসগুলোতে (Disposable addresses) শুধুমাত্র নন-প্রোডাকশন ডেটা থাকতে হবে।
- প্রিভিউ এনভায়রনমেন্টের (Preview environments) জন্য ক্লিনআপ রুলস প্রয়োজন।
এটি এড়িয়ে যাবেন না। সিস্টেমগুলোর মধ্যবর্তী ফাঁকা জায়গায় ইমেল ফ্লো ভেঙে পড়ে। এখানেই মক (mocks) সবচেয়ে দুর্বল।