בדיקת תהליכי שינוי אימייל ב-React מבלי להתבלבל בין קישורים
שינוי כתובת אימייל של חשבון נראה כמו עניין קטן. למעשה, זהו מקור מרכזי לשגיאות בדיקה.
בודקים מתבלבלים לעיתים קרובות בין קישורי אישור. אדם אחד מעדכן כתובת בזמן שאדם אחר פותח את ההודעה ראשון. זה יוצר בלבול. הצוות מתחיל להתווכח אם דף ה-React שבור או שהקישור שייך למשתמש הלא נכון.
הבעיה הזו קורה כי צוותים מתייחסים לתיבת הדואר הנכנס ככלי משותף. עליכם להתייחס לתיבת הדואר כחלק מחוזה הפיצ'ר (feature contract).
תהליכי שינוי אימייל הם שבירים. הם משנים חשבון פעיל. המשתמש כבר מחובר למערכת. לעיתים קרובות מתקיים "מרוץ" (race) בין מצב האימייל הממתין (pending) לבין מצב האימייל המאושר.
בעיות נפוצות כוללות:
- הודעות אישור מגיעות לתיבת דואר משותפת ללא דרך לעקוב אחריהן.
- ה-UI מציג נתונים ישנים גם לאחר שהקישור מאשר את הבקשה החדשה.
- ה-backend מתעדכן, אך ה-cache של ה-frontend מציג את הכתובת הישנה.
- בודק אחד לוחץ על קישור המיועד לאדם אחר.
תיבת דואר משותפת מקשה על מציאת סיבת הבאג. השתמשו בכתובת אימייל ייחודית ("burner email") עבור כל הרצת בדיקה במקום בכינוי (alias) אחד של סביבת staging.
עקבו אחר הרצף הנקי הזה:
- צרו משתמש בדיקה.
- בקשו שינוי אימייל במסך ההגדרות ב-React.
- שלחו את המייל דרך נתיב ה-backend האמיתי.
- נתבו את ההודעה לתיבת דואר השייכת אך ורק לבדיקה זו.
- פתחו את הקישור וודאו שמסך ההגדרות מתרענן עם הכתובת החדשה.
זה שומר על בהירות בבעלות. תדעו איזה קישור הגיע ממשתמש מסוים.
עבור אפליקציות React, פעלו לפי כלל נוסף אחד: בצעו assertion למסך רק לאחר קריאת נתונים טרייה. אל תסמכו על מצב לקוח אופטימי (optimistic client state). mutation עשוי להחזיר הצלחה, אך טעינה מחדש של הדף עלולה להחזיר את הערך הישן אם ה-backend לא סיים את תהליך השינוי.
בדיקת end-to-end טובה חייבת לוודא את הנקודות הבאות:
- האימייל נשלח לכתובת הממתינה ולא לכתובת הישנה.
- הקישור מפנה ל-host הנכון של הסביבה.
- הקישור מעדכן את רשומת החשבון.
- הכתובת הישנה נעלמת לאחר refetch.
- שימוש חוזר באותו קישור נכשל בצורה בטוחה.
אם ה-React query cache או ה-client store שלכם אינם מעודכנים (stale), הפיצ'ר ירגיש שבור. ללקוח אכפת רק מכך שמסך ההגדרות מציג את המציאות.
כדאי גם להוסיף correlation ID לכל בקשה. זה עוזר לכם לעקוב אחר בקשה מהמשתמש, דרך משלוח ההודעה ועד לאישור הסופי.
תיבות דואר מבודדות אינן מחליפות unit tests. השתמשו ב-unit tests עבור וולידציה של טפסים ושגיאות API. השתמשו בתזרים תיבת הדואר כדי להוכיח שמסלול הלקוח האמיתי עובד בכל המערכות.
לפני שאתם משיפים (ship) שינויים בהגדרות החשבון, בדקו את הפריטים הבאים:
- בקשו את השינוי מה-UI האמיתי של React.
- ודאו שההודעה מגיעה לתיבת דואר ספציפית להרצה.
- ודאו שהכתובת החדשה מופיעה לאחר refetch.
- ודאו שלא ניתן להשתמש שוב בקישור הישן.
- ודאו שיומני הביקורת (audit logs) מראים מי התחיל את השינוי.
זה מונע באגים שבהם הכל נראה תקין בבידוד, אך נכשל בעולם האמיתי.