લિંક્સ ચૂકી ગયા વગર ઈમેલ બદલવાની પ્રક્રિયાઓનું પરીક્ષણ કરો
એકાઉન્ટનો ઈમેલ બદલવો નાનું કામ લાગે છે. તે QA ટીમો માટે એક સામાન્ય જાળ છે. એક ટેસ્ટર સરનામું અપડેટ કરે છે. બીજી વ્યક્તિ પહેલા ઈમેલ ખોલે છે. હવે ટીમ વચ્ચે વિવાદ થાય છે કે React પેજ બગડી ગયું છે કે લિંક ખોટા વપરાશકર્તાની હતી.
જ્યારે તમે ઇનબોક્સને ફીચરના ભાગ તરીકે જોવાને બદલે એક શેર કરેલા સાધન તરીકે જુઓ છો, ત્યારે આ પ્રકારની મૂંઝવણ થાય છે.
ઈમેલ બદલવાની પ્રક્રિયાઓ નાજુક હોય છે. તેઓ સક્રિય એકાઉન્ટ્સમાં ફેરફાર કરે છે. તમારે પ્રમાણિત (authenticated) વપરાશકર્તાઓ અને પેન્ડિંગ સ્ટેટ્સ સાથે કામ કરવું પડે છે.
સામાન્ય સમસ્યાઓમાં શામેલ છે:
- સંદેશાઓ કોઈ સ્પષ્ટ માલિક વગરના શેર કરેલા ઇનબોક્સમાં આવે છે.
- લિંક કામ કરે છે, પરંતુ UI જૂનો ડેટા બતાવે છે.
- backend અપડેટ થાય છે, પરંતુ frontend cache જૂનું જ રહે છે.
- ટેસ્ટર્સ અન્ય ટેસ્ટર્સ માટે બનાવેલી લિંક પર ક્લિક કરે છે.
આને સુધારવા માટે, દરેક ટેસ્ટ રન માટે બર્નર ઈમેલ (burner email) નો ઉપયોગ કરો. એક જ સ્ટેજિંગ એલિયાસ (staging alias) નો ઉપયોગ કરશો નહીં.
આ ક્રમ અનુસરો:
- એપ દ્વારા ટેસ્ટ યુઝર બનાવો.
- React સેટિંગ્સમાં ઈમેલ બદલવાની વિનંતી કરો.
- રિયલ backend દ્વારા મેઈલ મોકલો.
- સંદેશને વન-રન ઇનબોક્સ (one-run inbox) પર રૂટ કરો.
- લિંક ખોલો અને સેટિંગ્સ સ્ક્રીન પર નવું સરનામું દેખાય છે તેની ખાતરી કરો.
આઇસોલેશન (Isolation) માલિકી સ્પષ્ટ રાખે છે. તમે કયો ઇનબોક્સ વાપર્યો હતો તે યાદ રાખવા માટે તમારે Slack માં અસ્તવ્યસ્ત નોટ્સ લખવાની જરૂર નહીં પડે.
React એપ્સ માટે એક નિયમ: હંમેશા તાજો ડેટા વાંચ્યા પછી સ્ક્રીન તપાસો. ઓપ્ટિમિસ્ટિક ક્લાયન્ટ સ્ટેટ (optimistic client state) પર વિશ્વાસ ન કરો. Mutation સફળતાપૂર્વક પૂર્ણ થઈ શકે છે, પરંતુ પેજ રિલોડ કરવાથી જૂની વેલ્યુ પાછી આવી શકે છે. આ બાબત લોકો સ્વીકારે તેના કરતા વધુ વાર બને છે.
તમારી end-to-end ટેસ્ટ આ બાબતોની ખાતરી કરવી જોઈએ:
- ઈમેલ નવા પેન્ડિંગ સરનામા પર જાય છે.
- લિંક સાચા હોસ્ટ (host) તરફ નિર્દેશ કરે છે.
- લિંક એકાઉન્ટ રેકોર્ડ અપડેટ કરે છે.
- રિફેટચ (refetch) પછી જૂનું સરનામું અદૃશ્ય થઈ જાય છે.
- લિંકનો ફરીથી ઉપયોગ કરવાથી તે સુરક્ષિત રીતે નિષ્ફળ જાય છે.
Frontend assertions સૌથી મહત્વનો ભાગ છે. જો વપરાશકર્તા ખોટું સરનામું જુએ છે, તો backend લોગમાં 'success' કહેવું નકામું છે. જો તમારું cache અથવા store જૂનું (stale) હોય, તો ફીચર બગડેલું છે.
ટ્રેસેબિલિટી (Traceability) પણ મદદ કરે છે. તમારા લોગ્સ અને ઈમેલ મેટાડેટામાં કોરિલેશન ID (correlation ID) નો ઉપયોગ કરો. આ વિનંતીને ડિલિવરી અને કન્ફર્મેશન સાથે જોડે છે.
ધ્યાનમાં લેવા જેવા ટ્રેડઓફ્સ (Tradeoffs):
- ઇનબોક્સ પોલિંગ (Inbox polling) મોક્સ (mocks) કરતા ધીમું છે.
- ડિસ્પોઝેબલ એડ્રેસમાં ફક્ત નોન-પ્રોડક્શન ડેટા જ હોવો જોઈએ.
- પ્રિવ્યૂ એન્વાયરમેન્ટ્સ (Preview environments) માટે ક્લીનઅપ નિયમોની જરૂર છે.
આને અવગણશો નહીં. સિસ્ટમ્સ વચ્ચેના અંતરાલમાં ઈમેલ ફ્લો તૂટી જાય છે. ત્યાં જ મોક્સ (mocks) સૌથી નબળા હોય છે.