React માં લિંક્સ મિક્સ કર્યા વગર ઈમેલ બદલવાની પ્રક્રિયાનું ટેસ્ટિંગ કરો
એકાઉન્ટનો ઈમેલ બદલવો નાનું કામ લાગે છે. વાસ્તવમાં તે ટેસ્ટિંગની ભૂલોનું એક મોટું કારણ છે.
ટેસ્ટર્સ ઘણીવાર કન્ફર્મેશન લિંક્સમાં ભૂલ કરી બેસે છે. એક વ્યક્તિ સરનામું અપડેટ કરે છે જ્યારે બીજી વ્યક્તિ પહેલા મેસેજ ખોલે છે. આનાથી મૂંઝવણ ઊભી થાય છે. ટીમ ચર્ચા કરવા લાગે છે કે React પેજ બગડી ગયું છે કે લિંક ખોટા યુઝરની છે.
આ સમસ્યા એટલા માટે થાય છે કારણ કે ટીમો ઇનબોક્સને એક શેર કરેલા સાધન તરીકે જુએ છે. તમારે ઇનબોક્સને ફીચર કોન્ટ્રાક્ટના ભાગ તરીકે ગણવું જોઈએ.
ઈમેલ બદલવાની પ્રક્રિયા નાજુક હોય છે. તે સક્રિય એકાઉન્ટમાં ફેરફાર કરે છે. યુઝર પહેલેથી જ લોગ-ઇન હોય છે. ઘણીવાર પેન્ડિંગ ઈમેલ અને કન્ફર્મ થયેલ ઈમેલ સ્ટેટ્સ વચ્ચે સ્પર્ધા (race condition) જોવા મળે છે.
સામાન્ય સમસ્યાઓમાં શામેલ છે:
- કન્ફર્મેશન મેસેજ શેર કરેલા ઇનબોક્સમાં આવે છે, જેનાથી તેને ટ્રેક કરવાનો કોઈ રસ્તો રહેતો નથી.
- લિંક દ્વારા નવી વિનંતી કન્ફર્મ થયા પછી પણ UI જૂનો ડેટા બતાવે છે.
- બેકએન્ડ અપડેટ થાય છે, પરંતુ ફ્રન્ટએન્ડ કેશ જૂનું સરનામું બતાવે છે.
- એક ટેસ્ટર બીજી વ્યક્તિ માટેની લિંક પર ક્લિક કરે છે.
શેર કરેલ મેઇલબોક્સ બગનું કારણ શોધવાનું મુશ્કેલ બનાવે છે. સિંગલ સ્ટેજિંગ એલિયાસને બદલે દરેક ટેસ્ટ રન માટે એક યુનિક બર્નર ઈમેલ એડ્રેસનો ઉપયોગ કરો.
આ સ્વચ્છ ક્રમ અનુસરો:
- ટેસ્ટ યુઝર બનાવો.
- React સેટિંગ્સ સ્ક્રીનમાં ઈમેલ બદલવાની વિનંતી કરો.
- રિયલ બેકએન્ડ પાથ દ્વારા મેઈલ મોકલો.
- મેસેજને એવા ઇનબોક્સમાં મોકલો જે ફક્ત આ ટેસ્ટ માટે જ હોય.
- લિંક ખોલો અને તપાસો કે સેટિંગ્સ સ્ક્રીન નવા સરનામા સાથે રિફ્રેશ થાય છે કે નહીં.
આનાથી માલિકી (ownership) સ્પષ્ટ રહે છે. તમને ખબર પડશે કે કઈ લિંક કયા યુઝર તરફથી આવી હતી.
React એપ્સ માટે, એક વધારાનો નિયમ અનુસરો. ડેટાના નવા રીડ (fresh data read) પછી જ સ્ક્રીનનું એસરશન (assert) કરો. ઓપ્ટિમિસ્ટિક ક્લાયન્ટ સ્ટેટ (optimistic client state) પર ભરોસો ન કરો. મ્યુટેશન (mutation) સફળતા દર્શાવી શકે છે, પરંતુ જો બેકએન્ડ ફેરફારને ફાઈનલ ન કરે, તો પેજ રીલોડ કરવાથી જૂની વેલ્યુ પાછી આવી શકે છે.
એક સારા એન્ડ-ટુ-એન્ડ ટેસ્ટમાં આ મુદ્દાઓ તપાસવા જોઈએ:
- ઈમેલ પેન્ડિંગ એડ્રેસ પર ગયો છે, જૂના એડ્રેસ પર નહીં.
- લિંક સાચા એન્વાયરમેન્ટ હોસ્ટ (environment host) તરફ નિર્દેશ કરે છે.
- લિંક એકાઉન્ટ રેકોર્ડ અપડેટ કરે છે.
- રિફેટચ (refetch) પછી જૂનું સરનામું ગાયબ થઈ જાય છે.
- એક જ લિંકનો ફરીથી ઉપયોગ કરવાથી સુરક્ષિત રીતે નિષ્ફળતા (fails safely) મળે છે.
જો તમારો React ક્વેરી કેશ (query cache) અથવા ક્લાયન્ટ સ્ટોર જૂનો (stale) હોય, તો ફીચર બગડેલું લાગે છે. ગ્રાહકને માત્ર એટલી જ ચિંતા હોય છે કે સેટિંગ્સ સ્ક્રીન વાસ્તવિકતા બતાવે છે કે નહીં.
તમારે દરેક વિનંતીમાં કોરિલેશન ID (correlation ID) પણ ઉમેરવું જોઈએ. આ તમને યુઝરથી લઈને મેસેજ ડિલિવરી અને અંતિમ કન્ફર્મેશન સુધીની વિનંતીને ટ્રેસ કરવામાં મદદ કરે છે.
અલગ ઇનબોક્સ યુનિટ ટેસ્ટનું સ્થાન લઈ શકતા નથી. ફોર્મ વેલિડેશન અને API ભૂલો માટે યુનિટ ટેસ્ટનો ઉપયોગ કરો. ઇનબોક્સ ફ્લોનો ઉપયોગ એ સાબિત કરવા માટે કરો કે વાસ્તવિક ગ્રાહક પાથ (customer path) તમામ સિસ્ટમ્સમાં કામ કરે છે.
એકાઉન્ટ સેટિંગ્સમાં ફેરફારો મોકલતા પહેલા, આ વસ્તુઓ તપાસો:
- રિયલ React UI માંથી ફેરફારની વિનંતી કરો.
- કન્ફર્મ કરો કે મેસેજ રન-સ્પેસિફિક (run-specific) ઇનબોક્સમાં આવે છે.
- રિફેટચ પછી નવું સરનામું દેખાય છે તેની ખાતરી કરો.
- ખાતરી કરો કે જૂની લિંકનો ફરીથી ઉપયોગ કરી શકાતો નથી.
- કન્ફર્મ કરો કે ઓડિટ લોગ્સ (audit logs) બતાવે છે કે ફેરફાર કોણે શરૂ કર્યો હતો.
આ એવા બગ્સને અટકાવે છે જ્યાં અલગથી બધું બરાબર લાગે છે પરંતુ વાસ્તવિક દુનિયામાં નિષ્ફળ જાય છે.