React-இல் லிங்குகளைக் குழப்பிக் கொள்ளாமல் மின்னஞ்சல் மாற்றும் முறைகளை (Email Change Flows) எவ்வாறு சோதனை செய்வது?
கணக்கின் மின்னஞ்சலை மாற்றுவது ஒரு சிறிய விஷயமாகத் தோன்றலாம். ஆனால், உண்மையில் இது சோதனைத் தவறுகள் (testing errors) ஏற்படுவதற்கு ஒரு முக்கிய காரணமாகும்.
சோதனையாளர்கள் (Testers) பெரும்பாலும் உறுதிப்படுத்தல் லிங்குகளைக் (confirmation links) குழப்பிக் கொள்கிறார்கள். ஒருவர் முகவரியைப் புதுப்பிக்கும்போது, மற்றொருவர் முதலில் செய்தியைத் திறந்துவிடுகிறார். இது குழப்பத்தை ஏற்படுத்துகிறது. React பக்கம் பழுதாகிவிட்டதா அல்லது அந்த லிங்க் தவறான பயனருக்கானதா என்று குழுவினர் விவாதிக்கத் தொடங்குவார்கள்.
குழுக்கள் இன்பாக்ஸை (inbox) ஒரு பொதுவான கருவியாகக் கருதுவதால் இந்தப் பிரச்சனை ஏற்படுகிறது. நீங்கள் இன்பாக்ஸை அந்த அம்சத்தின் (feature) ஒரு பகுதியாகக் கருத வேண்டும்.
மின்னஞ்சல் மாற்றும் செயல்முறைகள் (Email change journeys) மிகவும் நுணுக்கமானவை. அவை ஒரு செயல்பாட்டில் உள்ள கணக்கையே மாற்றுகின்றன. பயனர் ஏற்கனவே லாக்-இன் செய்திருப்பார். நிலுவையில் உள்ள மின்னஞ்சல் (pending email) மற்றும் உறுதிப்படுத்தப்பட்ட மின்னஞ்சல் (confirmed email) நிலைகளுக்கு இடையே பெரும்பாலும் ஒரு போட்டி நிலையை (race condition) உருவாக்கும்.
பொதுவான பிரச்சனைகள்:
- உறுதிப்படுத்தல் செய்திகள் ஒரு பொதுவான இன்பாக்ஸிற்கு வருகின்றன, அவற்றை உற்றுநோக்க (track) வழியில்லை.
- லிங்க் மூலம் புதிய கோரிக்கை உறுதி செய்யப்பட்ட பிறகும், UI பழைய தரவையே காட்டுகிறது.
- Backend புதுப்பிக்கப்படுகிறது, ஆனால் Frontend cache பழைய முகவያንமையே காட்டுகிறது.
- ஒரு சோதனையாளர் மற்றொருவருக்கான லிங்கைக் கிளிக் செய்கிறார்.
ஒரு பொதுவான மெயில் பாக்ஸ் (shared mailbox) ஒரு பிழையின் (bug) காரணத்தைக் கண்டறிவதைக் கடினமாக்குகிறது. ஒரு பொதுவான staging alias-க்கு பதிலாக, ஒவ்வொரு சோதனை ஓட்டத்திற்கும் (test run) ஒரு தனித்துவமான burner email முகவரியைப் பயன்படுத்துங்கள்.
இந்தத் தெளிவான வரிசையைப் பின்பற்றுங்கள்:
- ஒரு சோதனைப் பயனரை (test user) உருவாக்குங்கள்.
- React settings திரையில் மின்னஞ்சல் மாற்றத்தைக் கோருங்கள்.
- உண்மையான backend பாதையின் மூலம் மின்னஞ்சலை அனுப்புங்கள்.
- அந்தச் செய்தியை இந்தச் சோதனைக்கு மட்டுமே உரிய இன்பாக்ஸிற்குத் திருப்புங்கள் (route).
- லிங்கைத் திறந்து, settings திரை புதிய முகவரியுடன் புதுப்பிக்கப்படுவதை (refresh) உறுதிப்படுத்துங்கள்.
இது உரிமையைத் (ownership) தெளிவாக வைத்திருக்கும். எந்த லிங்க் எந்தப் பயனரிடமிருந்து வந்தது என்பதை நீங்கள் அறிந்து கொள்ளலாம்.
React செயலிகளுக்கு, ஒரு கூடுதல் விதியைப் பின்பற்றுங்கள். புதிய தரவைப் படித்த பின்னரே (fresh data read) திரையைச் சரிபார்க்கவும் (assert). 'Optimistic client state'-ஐ நம்ப வேண்டாம். ஒரு mutation வெற்றிகரமாகத் தோன்றலாம், ஆனால் backend மாற்றத்தை இறுதி செய்யவில்லை என்றால், பக்கத்தைப் புதுப்பிக்கும்போது (page reload) பழைய மதிப்பையே மீண்டும் கொண்டு வரக்கூடும்.
ஒரு சிறந்த end-to-end சோதனை இந்த விஷயங்களைச் சரிபார்க்க வேண்டும்:
- மின்னஞ்சல் பழைய முகவரிக்குச் செல்லாமல், நிலுவையில் உள்ள (pending) முகவரிக்குச் சென்றிருக்க வேண்டும்.
- லிங்க் சரியான environment host-ஐக் குறிக்க வேண்டும்.
- லிங்க் கணக்கின் பதிவைப் (account record) புதுப்பிக்க வேண்டும்.
- தரவை மீண்டும் எடுத்த பிறகு (refetch), பழைய முகவரி மறைந்துவிட வேண்டும்.
- அதே லிங்கை மீண்டும் பயன்படுத்த முயலும்போது அது பாதுகாப்பாகத் தோல்வியடைய வேண்டும்.
உங்கள் React query cache அல்லது client store பழைய தரவைக் கொண்டிருந்தால் (stale), அந்த அம்சம் பழுதாகியிருப்பதாகத் தோன்றும். settings திரை உண்மையான நிலையைத் காட்டுகிறதா என்பது மட்டுமே வாடிக்கையாளருக்கு முக்கியம்.
ஒவ்வொரு கோரிக்கைக்கும் (request) ஒரு correlation ID-யையும் நீங்கள் சேர்க்க வேண்டும். இது பயனரிடமிருந்து செய்தி விநியோகம் மற்றும் இறுதி உறுதிப்படுத்தல் வரை ஒரு கோரிக்கையைத் தொடர (trace) உங்களுக்கு உதவும்.
தனிமைப்படுத்தப்பட்ட இன்பாக்ஸ்கள் (Isolated inboxes) unit tests-களுக்கு மாற்றாகாது. Form validation மற்றும் API பிழைகளுக்கு unit tests-களைப் பயன்படுத்துங்கள். அனைத்து அமைப்புகளிலும் (systems) உண்மையான வாடிக்கையாளர் வழிமுறை சரியாகச் செயல்படுகிறது என்பதை நிரூபிக்க இன்பாக்ஸ் ஓட்டத்தைப் (inbox flow) பயன்படுத்துங்கள்.
கணக்கு அமைப்புகளில் (account settings) மாற்றங்களைச் செய்வதற்கு முன், இந்த விஷயங்களைச் சரிபார்க்கவும்:
- உண்மையான React UI-லிருந்து மாற்றத்தைக் கோருங்கள்.
- செய்தி அந்தத் குறிப்பிட்ட சோதனைக்கான (run-specific) இன்பாக்ஸிற்குச் செல்கிறதா என்பதை உறுதிப்படுத்துங்கள்.
- தரவை மீண்டும் எடுத்த பிறகு (refetch) புதிய முகவரி காட்டப்படுவதைச் சரிபார்க்கவும்.
- பழைய லிங்கை மீண்டும் பயன்படுத்த முடியாது என்பதை உறுதிப்படுத்தவும்.
- மாற்றத்தைத் தொடங்கியவர் யார் என்பதை audit logs காட்டுகிறதா என்பதை உறுதிப்படுத்தவும்.
இது தனித்தனியாகப் பார்க்கும்போது சரியாகத் தோன்றும், ஆனால் நிஜ உலகில் தோல்வியடையும் பிழைகளைத் தடுக்கிறது.