இணைப்புகளைத் தவறவிடாமல் மின்னஞ்சல் மாற்றச் செயல்பாடுகளைச் (Email Change Flows) சோதிக்கவும்
கணக்கின் மின்னஞ்சலை மாற்றுவது சிறிய விஷயமாகத் தோன்றலாம். ஆனால் இது QA குழுக்களுக்கு ஒரு பொதுவான சிக்கலாகும். ஒரு டெஸ்டர் முகவரியைப் புதுப்பிக்கிறார். மற்றொருவர் முதலில் மின்னஞ்சலைத் திறந்துவிடுகிறார். இப்போது React பக்கம் பழுதாகிவிட்டதா அல்லது அந்த இணைப்பு தவறான பயனருக்கானதா என்பதைப் பற்றி குழுவினர் விவாதிக்கத் தொடங்குவார்கள்.
மின்னஞ்சல் பெட்டியை (inbox) ஒரு அம்சத்தின் (feature) பகுதியாகக் கருதாமல், ஒரு பகிரப்பட்ட கருவியாகக் கருதும்போது இத்தகைய குழப்பங்கள் ஏற்படுகின்றன.
மின்னஞ்சல் மாற்றச் செயல்பாடுகள் (Email change journeys) மிகவும் நுணுக்கமானவை. அவை செயல்பாட்டில் உள்ள கணக்குகளை மாற்றியமைக்கின்றன. நீங்கள் அங்கீகரிக்கப்பட்ட பயனர்கள் (authenticated users) மற்றும் நிலுவையில் உள்ள நிலைகளைக் (pending states) கையாள வேண்டியிருக்கும்.
பொதுவான சிக்கல்களில் பின்வருவன அடங்கும்:
- தெளிவான உரிமையாளர் இல்லாத ஒரு பகிரப்பட்ட inbox-இல் செய்திகள் வருகின்றன.
- இணைப்பு வேலை செய்கிறது, ஆனால் UI பழைய தரவையே காட்டுகிறது.
- backend புதுப்பிக்கப்படுகிறது, ஆனால் frontend cache பழைய நிலையிலேயே உள்ளது.
- டெஸ்டர்கள் மற்ற டெஸ்டர்களுக்கான இணைப்புகளைக் கிளிக் செய்கிறார்கள்.
இதைச் சரிசெய்ய, ஒவ்வொரு சோதனை ஓட்டத்திற்கும் (test run) ஒரு தற்காலிக மின்னஞ்சலை (burner email) பயன்படுத்தவும். ஒரே ஒரு staging alias-ஐப் பயன்படுத்த வேண்டாம்.
இந்த வரிசையைப் பின்பற்றவும்:
- ஆப் மூலம் ஒரு டெஸ்ட் பயனரை உருவாக்கவும்.
- React settings-இல் மின்னஞ்சல் மாற்றத்தைக் கோரவும்.
- உண்மையான backend மூலம் மின்னஞ்சலை அனுப்பவும்.
- செய்தியை ஒருமுறை மட்டுமே பயன்படுத்தக்கூடிய inbox-க்கு அனுப்பவும்.
- இணைப்பைத் திறந்து, settings திரை புதிய முகவரியைக் காட்டுகிறதா என்பதைச் சரிபார்க்கவும்.
தனிமைப்படுத்துதல் (Isolation) உரிமையைத் தெளிவாக வைத்திருக்கும். நீங்கள் எந்த inbox-ஐப் பயன்படுத்தினீர்கள் என்பதை நினைவில் கொள்ள Slack-இல் குழப்பமான குறிப்புகளை எழுத வேண்டிய அவசியமில்லை.
React ஆப்ஸ்களுக்கான ஒரு விதி: புதிய தரவைப் படித்த பிறகு எப்போதும் திரையைச் சரிபார்க்கவும். optimistic client state-ஐ நம்ப வேண்டாம். mutation வெற்றிகரமாக முடிந்திருக்கலாம், ஆனால் பக்கத்தைப் புதுப்பிக்கும்போது (page reload) பழைய மதிப்பு மீண்டும் வரக்கூடும். இது மக்கள் ஒப்புக்கொள்வதை விட அடிக்கடி நடக்கும்.
உங்கள் end-to-end test இவற்றைச் சரிபார்க்க வேண்டும்:
- மின்னஞ்சல் புதிய நிலுவையில் உள்ள முகவரிக்குச் செல்கிறதுவா?
- இணைப்பு சரியான host-ஐக் குறிக்கிறதா?
- இணைப்பு கணக்குத் தரவைப் (account record) புதுப்பிக்கிறதா?
- refetch செய்த பிறகு பழைய முகவரி மறைந்துவிடுகிறதா?
- இணைப்பை மீண்டும் பயன்படுத்தும்போது பாதுகாப்பாகத் தோல்வியடைகிறதா?
Frontend assertions தான் மிக முக்கியமான பகுதி. பயனர் தவறான முகவரியைப் பார்த்தால், backend log 'வெற்றி' என்று சொன்னாலும் அது பயனற்றது. உங்கள் cache அல்லது store பழைய தரவைக் கொண்டிருந்தால், அந்த அம்சம் பழுதாகியுள்ளது என்று அர்த்தம்.
Traceability-யும் உதவும். உங்கள் logs மற்றும் email metadata-வில் ஒரு correlation ID-யைப் பயன்படுத்தவும். இது கோரிக்கையை (request), விநியோகத்துடனும் (delivery) மற்றும் உறுதிப்படுத்தலுடனும் (confirmation) இணைக்கிறது.
கவனிக்க வேண்டிய மாற்றங்கள் (Tradeoffs):
- Inbox polling என்பது mocks-ஐ விட மெதுவானது.
- தற்காலிக முகவரிகளில் (disposable addresses) உற்பத்தித் தரவு (production data) இருக்கக்கூடாது.
- Preview environments-க்கு சுத்திகரிப்பு விதிகள் (cleanup rules) தேவை.
இதைத் தவிர்க்க வேண்டாம். அமைப்புகளுக்கு இடையிலான இடைவெளிகளில்தான் (gaps between systems) மின்னஞ்சல் செயல்பாடுகள் முறிவடைகின்றன. அங்குதான் mocks மிகவும் பலவீனமாக இருக்கும்.