లింక్లను మిస్ కాకుండా ఈమెయిల్ మార్పు ప్రక్రియలను (Email Change Flows) పరీక్షించండి
అకౌంట్ ఈమెయిల్ మార్చడం అనేది చిన్న విషయంలా అనిపించవచ్చు. కానీ ఇది QA టీమ్లకు ఒక సాధారణ చిక్కుముడి. ఒక టెస్టర్ అడ్రస్ను అప్డేట్ చేస్తారు. మరొక వ్యక్తి మొదటగా ఆ ఈమెయిల్ను ఓపెన్ చేస్తారు. ఇప్పుడు React పేజీ పాడైపోయిందా లేదా ఆ లింక్ తప్పు యూజర్కు చెందినదా అనే విషయంపై టీమ్ మధ్య గొడవలు జరుగుతాయి.
ఈమెయిల్ ఇన్బాక్స్ను ఫీచర్లో భాగంగా కాకుండా, కేవలం ఒక షేర్డ్ టూల్గా పరిగణించినప్పుడు ఇలాంటి గందరగోళం ఏర్పడుతుంది.
ఈమెయిల్ మార్పు ప్రక్రియలు (Email change journeys) చాలా సున్నితమైనవి. ఇవి యాక్టివ్గా ఉన్న అకౌంట్లను మారుస్తాయి. మీరు అథెంటికేటెడ్ యూజర్లు మరియు పెండింగ్ స్టేట్స్తో డీల్ చేయాల్సి ఉంటుంది.
సాధారణ సమస్యలలో ఇవి ఉన్నాయి:
- స్పష్టమైన యజమాని లేని షేర్డ్ ఇన్బాక్స్లోకి మెసేజ్లు రావడం.
- లింక్ పనిచేస్తుంది, కానీ UI పాత డేటాను చూపిస్తుంది.
- బ్యాకెండ్ అప్డేట్ అవుతుంది, కానీ ఫ్రంటెండ్ క్యాష్ (cache) పాతదిగానే ఉంటుంది.
- టెస్టర్లు ఇతర టెస్టర్ల కోసం ఉద్దేశించిన లింక్లను క్లిక్ చేయడం.
దీనిని పరిష్కరించడానికి, ప్రతి టెస్ట్ రన్ కోసం ఒక బర్నర్ ఈమెయిల్ (burner email) ఉపయోగించండి. ఒకే స్టేజింగ్ ఏలియాస్ను (staging alias) ఉపయోగించవద్దు.
ఈ క్రమాన్ని అనుసరించండి:
- యాప్ ద్వారా ఒక టెస్ట్ యూజర్ను సృష్టించండి.
- React సెట్టింగ్స్లో ఈమెయిల్ మార్పు కోసం రిక్వెస్ట్ చేయండి.
- రియల్ బ్యాకెండ్ ద్వారా మెయిల్ పంపండి.
- మెసేజ్ను ఒకేసారి వాడే ఇన్బాక్స్కు (one-run inbox) పంపండి.
- లింక్ను ఓపెన్ చేసి, సెట్టింగ్స్ స్క్రీన్ కొత్త అడ్రస్ను చూపిస్తుందో లేదో ధృవీకరించండి.
ఐసోలేషన్ (Isolation) వల్ల యజమాని ఎవరో స్పష్టంగా ఉంటుంది. మీరు ఏ ఇన్బాక్స్ను ఉపయోగించారో గుర్తుంచుకోవడానికి Slackలో గందరగోళమైన నోట్స్ రాసుకోవాల్సిన అవసరం ఉండదు.
React యాప్ల కోసం ఒక నియమం: డేటా రీడ్ చేసిన తర్వాత ఎల్లప్పుడూ స్క్రీన్ను తనిఖీ చేయండి. ఆప్టిమిస్టిక్ క్లయింట్ స్టేట్ (optimistic client state) పై నమ్మకం ఉంచకండి. మ్యుటేషన్ (mutation) సక్సెస్ అని చూపించవచ్చు, కానీ పేజీ రీలోడ్ చేసినప్పుడు పాత విలువ మళ్ళీ రావచ్చు. ఇది ప్రజలు ఒప్పుకున్న దానికంటే ఎక్కువగా జరుగుతుంది.
మీ ఎండ్-టు-ఎండ్ (end-to-end) టెస్ట్ వీటిని ధృవీకరించాలి:
- ఈమెయిల్ కొత్త పెండింగ్ అడ్రస్కు వెళ్తుంది.
- లింక్ సరైన హోస్ట్ను సూచిస్తుంది.
- లింక్ అకౌంట్ రికార్డ్ను అప్డేట్ చేస్తుంది.
- రిఫెచ్ (refetch) చేసిన తర్వాత పాత అడ్రస్ కనిపించకుండా పోతుంది.
- అదే లింక్ను మళ్ళీ వాడితే సురక్షితంగా ఫెయిల్ అవుతుంది.
ఫ్రంటెండ్ అసర్షన్స్ (Frontend assertions) అత్యంత ముఖ్యమైన భాగం. యూజర్ తప్పు అడ్రస్ను చూస్తుంటే, బ్యాకెండ్ లాగ్ 'సక్సెస్' అని చెప్పడం వల్ల ఉపయోగం లేదు. మీ క్యాష్ లేదా స్టోర్ పాతదిగా ఉంటే, ఆ ఫీచర్ విఫలమైనట్లే.
ట్రేసిబిలిటీ (Traceability) కూడా సహాయపడుతుంది. మీ లాగ్స్ మరియు ఈమెయిల్ మెటాడేటాలో ఒక కోరిలేషన్ ఐడి (correlation ID) ఉపయోగించండి. ఇది రిక్వెస్ట్ను డెలివరీ మరియు కన్ఫర్మేషన్తో అనుసంధానిస్తుంది.
పరిగణించవలసిన లాభనష్టాలు (Tradeoffs):
- ఇన్బాక్స్ పోలింగ్ (Inbox polling) మోక్స్ (mocks) కంటే నెమ్మదిగా ఉంటుంది.
- డిస్పోజబుల్ అడ్రస్లలో కేవలం నాన్-ప్రొడక్షన్ డేటా మాత్రమే ఉండాలి.
- ప్రివ్యూ ఎన్విరాన్మెంట్లకు క్లీనప్ రూల్స్ అవసరం.
దీనిని వదిలివేయకండి. సిస్టమ్ల మధ్య ఉండే ఖాళీలలో ఈమెయిల్ ఫ్లోలు విఫలమవుతాయి. అక్కడే మోక్స్ (mocks) బలహీనంగా ఉంటాయి.