בדיקת התחברות ללא סיסמה ללא כאוס בתיבת הדואר הנכנס
התחברות ללא סיסמה נראית קלה בהדגמה. משתמש מזין אימייל, מקבל magic link, ומתחבר.
בסביבת ה-staging, התהליך הזה נשבר. קישורים מגיעים לתיבות דואר משותפות או לכינויי אימייל (aliases) ישנים. הבדיקות הופכות לבלגן.
עליכם להתייחס לאימות ללא סיסמה כמערכת אחת שלמה. עליכם לבדוק את ה-JavaScript client, את ה-Node.js backend, את משלוח האימייל ואת ה-session הסופי.
אם תדלגו על תיבת הדואר, בדיקות ה-API שלכם עשויות לעבור בעוד שחוויית המשתמש נכשלת.
כשלים נפוצים כוללים:
- ה-backend שולח שני קישורים לאחר ניסיון חוזר (retry).
- האימייל מפנה ל-host של סביבה לא נכונה.
- קישור ישן עובד זמן רב יותר ממה שהוא אמור.
- ה-frontend מסמן את המשתמש כמתחבר לפני שה-cookie מוגדר.
השתמשו בתיבת דואר מבודדת עבור כל הרצת בדיקה. זה שומר על הנתונים שלכם נקיים ומאיץ את הדיבאגינג (debugging). אם שלוש בדיקות משתמשות בתיבה אחת, לא תוכלו למצוא את השגיאה.
עקבו אחר תהליך העבודה הזה:
- הפעילו את ההתחברות מה-UI שלכם או מבדיקת end-to-end.
- אפשרו ל-Node.js לשלוח את הקישור דרך נתיב ה-staging שלכם.
- תפסו את ההודעה בתיבת דואר חדשה ומבודדת.
- פתחו את הקישור החדש ביותר באותו session של הדפדפן.
- ודאו את מצב האימות (authenticated state).
בדיקה טובה עושה יותר מאשר רק לבדוק אם אימייל הגיע. בדקו את השלבים הבאים לפי הסדר:
- בקשת ההתחברות מחזירה תגובת הצלחה ניטרלית.
- קיים בדיוק magic link אחד חדש.
- ה-host של הקישור תואם לדומיין ה-staging שלכם.
- ה-token מתחיל session תקף.
- שימוש חוזר באותו קישור נכשל.
- האפליקציה מעדכנת את ה-UI ללא רענון ידני.
ב-backend, צרפו correlation ID ללוגים (logs) שלכם. זה עוזר לכם לעקוב אחר בקשה מיצירתה ועד ל-session הסופי.
אל תחליפו את כל הבדיקות שלכם בבדיקות מבוססות אימייל. השתמשו ב-unit tests מהירים עבור הלוגיקה והשתמשו בנתיב תיבת הדואר הזה עבור סדרת בדיקות ה-staging שלכם.
השתמשו בצ'קליסט הזה לפני שאתם מפיצים (ship):
- בקשת התחברות יוצרת רק קישור פעיל אחד.
- האימייל החדש ביותר קל לניתוח (parse) ב-staging.
- הקישור מבצע התחברות למשתמש ב-host הנכון.
- לא ניתן להשתמש בקישור פעמיים.
- התנתקות והתחברות מחדש מייצרות token חדש ונקי.