ಲಿಂಕ್ಗಳನ್ನು ಗೊಂದಲಕ್ಕೀಡುಮಾಡದೆ React ನಲ್ಲಿ ಇಮೇಲ್ ಬದಲಾವಣೆ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ
ಅಕೌಂಟ್ ಇಮೇಲ್ ಬದಲಾಯಿಸುವುದು ಸಣ್ಣ ವಿಷಯದಂತೆ ಕಾಣಬಹುದು. ಆದರೆ ವಾಸ್ತವವಾಗಿ ಇದು ಪರೀಕ್ಷಾ ದೋಷಗಳಿಗೆ (testing errors) ಪ್ರಮುಖ ಕಾರಣವಾಗಿದೆ.
ಪರೀಕ್ಷಕರು (Testers) ಆಗಾಗ್ಗೆ ಕನ್ಫರ್ಮೇಷನ್ ಲಿಂಕ್ಗಳನ್ನು ಗೊಂದಲಕ್ಕೀಡುಮಾಡಿಕೊಳ್ಳುತ್ತಾರೆ. ಒಬ್ಬ ವ್ಯಕ್ತಿಯು ವಿಳಾಸವನ್ನು ಅಪ್ಡೇಟ್ ಮಾಡುತ್ತಿರುವಾಗ, ಇನ್ನೊಬ್ಬ ವ್ಯಕ್ತಿಯು ಮೊದಲು ಸಂದೇಶವನ್ನು ತೆರೆಯಬಹುದು. ಇದು ಗೊಂದಲವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ. React ಪೇಜ್ ಕೆಟ್ಟುಹೋಗಿದೆಯೇ ಅಥವಾ ಲಿಂಕ್ ತಪ್ಪು ಬಳಕೆದಾರರಿಗೆ ಸೇರಿದ್ದೇ ಎಂಬ ಬಗ್ಗೆ ತಂಡವು ಚರ್ಚಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ.
ತಂಡಗಳು ಇನ್ಬಾಕ್ಸ್ ಅನ್ನು ಒಂದು ಹಂಚಿಕೆಯ ಸಾಧನವಾಗಿ (shared tool) ಪರಿಗಣಿಸುವುದರಿಂದ ಈ ಸಮಸ್ಯೆ ಉಂಟಾಗುತ್ತದೆ. ನೀವು ಇನ್ಬಾಕ್ಸ್ ಅನ್ನು ಫೀಚರ್ ಕಾಂಟ್ರಾಕ್ಟ್ನ (feature contract) ಒಂದು ಭಾಗವಾಗಿ ಪರಿಗಣಿಸಬೇಕು.
ಇಮೇಲ್ ಬದಲಾವಣೆಯ ಪ್ರಕ್ರಿಯೆಗಳು (journeys) ಅಸ್ಥಿರವಾಗಿರುತ್ತವೆ. ಅವು ಸಕ್ರಿಯ ಅಕೌಂಟ್ ಅನ್ನು ಬದಲಾಯಿಸುತ್ತವೆ. ಬಳಕೆದಾರರು ಈಗಾಗಲೇ ಲಾಗ್ ಇನ್ ಆಗಿರುತ್ತಾರೆ. ಪೆಂಡಿಂಗ್ ಇಮೇಲ್ ಮತ್ತು ಕನ್ಫರ್ಮ್ ಆದ ಇಮೇಲ್ ಸ್ಥಿತಿಗಳ (states) ನಡುವೆ ಆಗಾಗ್ಗೆ ಸ್ಪರ್ಧೆ (race condition) ಇರುತ್ತದೆ.
ಸಾಮಾನ್ಯ ಸಮಸ್ಯೆಗಳು ಇಂತಿವೆ:
- ಕನ್ಫರ್ಮೇಷನ್ ಸಂದೇಶಗಳು ಹಂಚಿಕೆಯ ಇನ್ಬಾಕ್ಸ್ಗೆ ಬರುತ್ತವೆ ಮತ್ತು ಅವುಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಲು ಯಾವುದೇ ಮಾರ್ಗವಿರುವುದಿಲ್ಲ.
- ಲಿಂಕ್ ಹೊಸ ವಿನಂತಿಯನ್ನು ಕನ್ಫರ್ಮ್ ಮಾಡಿದ ನಂತರವೂ UI ಹಳೆಯ ಡೇಟಾವನ್ನು ತೋರಿಸುತ್ತದೆ.
- backend ಅಪ್ಡೇಟ್ ಆಗುತ್ತದೆ, ಆದರೆ frontend cache ಹಳೆಯ ವಿಳಾಸವನ್ನೇ ತೋರಿಸುತ್ತದೆ.
- ಒಬ್ಬ ಪರೀಕ್ಷಕರು ಇನ್ನೊಬ್ಬರಿಗೆ ಮೀಸಲಾದ ಲಿಂಕ್ ಅನ್ನು ಕ್ಲಿಕ್ ಮಾಡುತ್ತಾರೆ.
ಹಂಚಿಕೆಯ ಮೇಲ್ಬಾಕ್ಸ್ ಬಳಕೆಯಿಂದ ಬಗ್ನ (bug) ಕಾರಣವನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಕಷ್ಟವಾಗುತ್ತದೆ. ಒಂದೇ ಸ್ಟೇಜಿಂಗ್ ಏಲಿಯಾಸ್ (staging alias) ಬದಲಿಗೆ ಪ್ರತಿ ಟೆಸ್ಟ್ ರನ್ಗಾಗಿ ವಿಶಿಷ್ಟವಾದ ಬರ್ನರ್ ಇಮೇಲ್ ವಿಳಾಸವನ್ನು (burner email address) ಬಳಸಿ.
ಈ ಸ್ಪಷ್ಟವಾದ ಕ್ರಮವನ್ನು ಅನುಸರಿಸಿ:
- ಟೆಸ್ಟ್ ಬಳಕೆದಾರರನ್ನು ರಚಿಸಿ.
- React settings ಸ್ಕ್ರೀನ್ನಲ್ಲಿ ಇಮೇಲ್ ಬದಲಾವಣೆಗೆ ವಿನಂತಿಸಿ.
- ನೈಜ backend ಪಾತ್ ಮೂಲಕ ಇಮೇಲ್ ಕಳುಹಿಸಿ.
- ಸಂದೇಶವನ್ನು ಕೇವಲ ಈ ಟೆಸ್ಟ್ಗೆ ಮಾತ್ರ ಸೇರಿದ ಇನ್ಬಾಕ್ಸ್ಗೆ ಕಳುಹಿಸಿ (route).
- ಲಿಂಕ್ ಅನ್ನು ತೆರೆಯಿರಿ ಮತ್ತು settings ಸ್ಕ್ರೀನ್ ಹೊಸ ವಿಳಾಸದೊಂದಿಗೆ ರಿಫ್ರೆಶ್ ಆಗುತ್ತಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ.
ಇದು ಮಾಲೀಕತ್ವವನ್ನು (ownership) ಸ್ಪಷ್ಟವಾಗಿರಿಸುತ್ತದೆ. ಯಾವ ಲಿಂಕ್ ಯಾವ ಬಳಕೆದಾರರಿಂದ ಬಂದಿದೆ ಎಂಬುದು ನಿಮಗೆ ತಿಳಿಯುತ್ತದೆ.
React ಅಪ್ಲಿಕೇಶನ್ಗಳಿಗಾಗಿ, ಒಂದು ಹೆಚ್ಚುವರಿ ನಿಯಮವನ್ನು ಅನುಸರಿಸಿ. ಹೊಸ ಡೇಟಾ ಓದಿದ ನಂತರವಷ್ಟೇ ಸ್ಕ್ರೀನ್ ಅನ್ನು assert ಮಾಡಿ. ಆಪ್ಟಿಮಿಸ್ಟಿಕ್ ಕ್ಲೈಂಟ್ ಸ್ಟೇಟ್ (optimistic client state) ಅನ್ನು ನಂಬಬೇಡಿ. ಒಂದು mutation ಯಶಸ್ಸನ್ನು ನೀಡಬಹುದು, ಆದರೆ backend ಬದಲಾವಣೆಯನ್ನು ಅಂತಿಮಗೊಳಿಸದಿದ್ದರೆ, ಪೇಜ್ ರಿಲೋಡ್ ಮಾಡಿದಾಗ ಹಳೆಯ ಮೌಲ್ಯವೇ ಮರಳಿ ಬರಬಹುದು.
ಉತ್ತಮ ಎಂಡ್-ಟು-ಎಂಡ್ (end-to-end) ಪರೀಕ್ಷೆಯು ಈ ಅಂಶಗಳನ್ನು ಪರಿಶೀಲಿಸಬೇಕು:
- ಇಮೇಲ್ ಹಳೆಯ ವಿಳಾಸಕ್ಕೆ ಹೋಗದೆ ಪೆಂಡಿಂಗ್ ವಿಳಾಸಕ್ಕೆ ಹೋಗಿದೆ.
- ಲಿಂಕ್ ಸರಿಯಾದ ಎನ್ವಿರಾನ್ಮೆಂಟ್ ಹೋಸ್ಟ್ (environment host) ಅನ್ನು ಸೂಚಿಸುತ್ತದೆ.
- ಲಿಂಕ್ ಅಕೌಂಟ್ ರೆಕಾರ್ಡ್ ಅನ್ನು ಅಪ್ಡೇಟ್ ಮಾಡುತ್ತದೆ.
- ರಿಫೆಚ್ (refetch) ಮಾಡಿದ ನಂತರ ಹಳೆಯ ವಿಳಾಸ ಮಾಯವಾಗುತ್ತದೆ.
- ಅದೇ ಲಿಂಕ್ ಅನ್ನು ಮರುಬಳಕೆ ಮಾಡಿದಾಗ ಅದು ಸುರಕ್ಷಿತವಾಗಿ ಫೇಲ್ ಆಗುತ್ತದೆ.
ನಿಮ್ಮ React query cache ಅಥವಾ client store ಹಳೆಯದಾಗಿದ್ದರೆ (stale), ಫೀಚರ್ ಕೆಟ್ಟುಹೋದಂತೆ ಭಾಸವಾಗುತ್ತದೆ. settings ಸ್ಕ್ರೀನ್ ವಾಸ್ತವವನ್ನು ತೋರಿಸುತ್ತಿದೆಯೇ ಎಂಬುದು ಮಾತ್ರ ಗ್ರಾಹಕರಿಗೆ ಮುಖ್ಯವಾಗುತ್ತದೆ.
ನೀವು ಪ್ರತಿ ವಿನಂತಿಗೆ (request) ಒಂದು ಕೊರಿಲೇಷನ್ ಐಡಿ (correlation ID) ಅನ್ನು ಕೂಡ ಸೇರಿಸಬೇಕು. ಇದು ಬಳಕೆದಾರರಿಂದ ಸಂದೇಶ ವಿತರಣೆ ಮತ್ತು ಅಂತಿಮ ಕನ್ಫರ್ಮೇಷನ್ ವರೆಗೆ ವಿನಂತಿಯನ್ನು ಟ್ರೇಸ್ ಮಾಡಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.
ಪ್ರತ್ಯೇಕ ಇನ್ಬಾಸ್ಗಳು ಯೂನಿಟ್ ಟೆಸ್ಟ್ಗಳಿಗೆ (unit tests) ಪರ್ಯಾಯವಲ್ಲ. ಫಾರ್ಮ್ ವ್ಯಾಲಿಡೇಶನ್ ಮತ್ತು API ದೋಷಗಳಿಗಾಗಿ ಯೂನಿಟ್ ಟೆಸ್ಟ್ಗಳನ್ನು ಬಳಸಿ. ಎಲ್ಲಾ ಸಿಸ್ಟಮ್ಗಳಲ್ಲಿ ನೈಜ ಗ್ರಾಹಕರ ಹಾದಿ (customer path) ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸಲು ಇನ್ಬಾಕ್ಸ್ ಫ್ಲೋ ಅನ್ನು ಬಳಸಿ.
ಅಕೌಂಟ್ ಸೆಟ್ಟಿಂಗ್ಗಳಿಗೆ ಬದಲಾವಣೆಗಳನ್ನು ಕಳುಹಿಸುವ (ship) ಮೊದಲು, ಈ ಅಂಶಗಳನ್ನು ಪರಿಶೀಲಿಸಿ:
- ನೈಜ React UI ನಿಂದ ಬದಲಾವಣೆಗೆ ವಿನಂತಿಸಿ.
- ಸಂದೇಶವು ರನ್-ನಿರ್ದಿಷ್ಟ (run-specific) ಇನ್ಬಾಕ್ಸ್ಗೆ ತಲುಪಿದೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.
- ರಿಫೆಚ್ ಮಾಡಿದ ನಂತರ ಹೊಸ ವಿಳಾಸವು ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ.
- ಹಳೆಯ ಲಿಂಕ್ ಅನ್ನು ಮರುಬಳಕೆ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.
- ಬದಲಾವಣೆಯನ್ನು ಯಾರು ಪ್ರಾರಂಭಿಸಿದರು ಎಂದು ಆಡಿಟ್ ಲಾಗ್ಗಳು (audit logs) ತೋರಿಸುತ್ತಿವೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.
ಇದು ಪ್ರತ್ಯೇಕವಾಗಿ ಎಲ್ಲವೂ ಸರಿಯಾಗಿ ಕಾಣಿಸಿದರೂ, ನೈಜ ಜಗತ್ತಿನಲ್ಲಿ ವಿಫಲವಾಗುವ ಬಗ್ಗಳನ್ನು ತಡೆಯುತ್ತದೆ.