הודעת אישור היא החלק בתהליך ההרשמה שבדיקת דפדפן אינה יכולה להפעיל לבדה. משהו צריך להחזיק כתובת, לקבל את ההודעה ולהחזיר את הקוד לבדיקה. API של תיבת דואר זמנית עושה בדיוק את זה: המערך מבקש משירות ליצור תיבה ב-HTTP, קורא את מה שמגיע, וזורק את התיבה כשהמקרה מסתיים. אין דפדפן, אין תיבת דואר אנושית משותפת ואין העתקה ידנית.
המאמר הזה עוסק בצד ה-API של הסידור הזה. הוא אינו עוסק בהפניית היישום לקצה קבלה מקומי, שכן זהו לכידת דואר ב-CI, והשניים פותרים בעיות שונות. לכידה מקומית מוכיחה מה היישום שלך שולח. API של תיבה מוכיח מה באמת מגיע, בנתיב מסירה אמיתי, לכתובת שהבדיקה מחזיקה.
למה להשתמש ב-API של תיבה בבדיקות?
כי החלופה היא תיבת דואר אנושית אמיתית, או כלום.
תיבה משותפת היא כלי בדיקה גרוע. כמה הרצות קוראות מאותה תיבה, הודעות מהרצה קודמת עוד מונחות שם, והכתובת צוברת תנועה שאף בדיקה לא ביקשה. כל הצהרה צריכה אז לנחש איזו הודעה שייכת למקרה הנוכחי, ובניחוש נולד חוסר היציבות.
קציר ממשק האינטרנט של ספק עם דפדפן הוא האפשרות הרעה השנייה. היא תולה את הבדיקה בקידוד שמשתנה בלי הודעה, במצב הפעלה, ובהתחברות שהמערך צריך להשגיח עליה. ברגע שהספק מעצב מחדש כפתור, מערך ירוק הופך לאדום מסיבה שאין לה קשר למוצר.
API של תיבה מסיר את שתי הבעיות. הכתובת נוצרת עבור המקרה, היא ריקה מעצם טבעה, והיא נקראת דרך ממשק יציב שהבדיקה יכולה לקרוא לו ישירות. המערך כבר לא מתעניין איך נראה הספק, אלא רק שהחוזה מחזיק: ליצור, לקבל, לקרוא, למחוק.
יש גם טיעון פרטיות. כתובת שנוצרה דרך API אינה מייצגת איש. היא אינה תיבת דואר של אדם, היא אינה מקום שבו הודעה אמיתית יכולה לנחות, והיא נזרקת עם ההרצה.
אילו נקודות קצה באמת צריך בדיקה?
API של תיבה יכול לחשוף עשרות נתיבים, אבל לקוח בדיקה צריך ארבע פעולות, וכדאי לתת להן שמות כפי שהמערך ישתמש בהן.
יצירה מחזירה כתובת וידית. הכתובת היא מה שאומרים ליישום הנבדק לשלוח אליו. הידית, שלעיתים קרובות היא אסימון או מזהה, היא מה שהבדיקה משתמשת בו כדי לשאול על התיבה הזו בכל קריאה מאוחרת. המערך צריך להתייחס לזוג כאל אובייקט אחד ולעולם לא לבנות את הידית מחדש מהכתובת, כי ספקים חופשיים לעשות את השתיים בלתי תלויות.
רישום מחזיר תקצירים ולא גופים: רשומה אחת לכל הודעה, עם מזהה, השולח, שורת הנושא וזמן ההגעה. זו הקריאה שלולאת סקירה צריכה להשתמש בה, כי היא זולה ומספיקה כדי לענות על השאלה היחידה שחשובה בהתחלה, כלומר אם משהו כבר הגיע.
קריאה מחזירה הודעה אחת במלואה, כולל חלקי טקסט ו-HTML. שם חי הקוד, וזו הקריאה שיש לבצע רק אחרי שרישום דיווח על התאמה.
ריקון מסיר את ההודעות מתיבה או מוחק את התיבה כולה. בדיקה צריכה אותו משתי סיבות: לאפס בין ניסיונות בלי ליצור כתובת חדשה, ולנקות כשהמקרה מסתיים.
חלק מהשירותים מוסיפים נקודת המתנה או סקירה ארוכה, שמחזיקה את החיבור עד שמגיעה הודעה או שנגמר מועד. זה נוח, אבל לקוח עדיין צריך להיות מסוגל לחזור לרישום, כי קריאת ההמתנה היא החלק שסביר ביותר שיוגבל בקצב.
לסקור את הקוד בלי חוסר יציבות
הטעות הנפוצה ביותר בבדיקה מסוג זה היא המתנה קבועה. מספר קבוע של שניות הוא ניחוש: קצר מדי כשהמסירה איטית, ארוך באופן בזבזני כשהיא מהירה, ושגוי בשני הכיוונים על מכונת CI עמוסה. החלף אותו בלולאה שקוראת לרישום, בודקת התאמה וחוזרת ברגע שנמצאה, עם תקרה שמפילה את הבדיקה במקום לתלות את המשימה.
ההתאמה היא החצי השני של הבעיה. ההודעה שהבדיקה רוצה היא זו שנשלחה לכתובת שהמקרה יצר, ואם התיבה יכולה להחזיק יותר מסוג דואר אחד, זו ששורת הנושא שלה נושאת שבר יציב. העדף את ההתאמה החדשה ביותר, כדי שמסירה כפולה מניסיון חוזר לא תבלבל את הקריאה. לעולם אל תיקח את ההודעה הראשונה בלי תנאי; על כתובת שמשמשת מחדש, כך בדיוק קוד ישן מאומת.
החילוץ צריך להיות מעוגן. גוף עשוי להכיל מספר אסמכתה, חתימת זמן ומחיר, ומנתח שלוכד את רצף הספרות הראשון יתפוס לעיתים אחד מאלה במקום את הקוד. חפש את הניסוח שמציג את הקוד, קרא את הקוד מסביבתו, והיכשל עם הגוף מצורף כשלא מתאים דבר.
ולבסוף, כבד את מגבלת השליחה החוזרת. תהליך קוד מתיר בדרך כלל רק כמה שליחות בחלון קצר, והמגבלה הזו היא חלק מההתנהגות הנבדקת. בדיקה שלוחצת שוב על הכפתור כדי לקבל קוד טרי תידחה בסופו של דבר ותיכשל מהסיבה הלא נכונה. נסה שוב על ידי קריאה חוזרת של התיבה, לא על ידי עידוד הודעה נוספת.
לחבר את זה למערך מקצה לקצה או ל-CI
הצורה הנקייה היא כלי בדיקה. לפני שהתהליך מתחיל, כלי הבדיקה יוצר תיבה ומחזיר את כתובתה. הבדיקה מפעילה את היישום עם הכתובת הזו. אחרי שהיישום מאשר ששלח משהו, ההצהרה קוראת את התיבה ומחלצת את הקוד. כשהמקרה מסתיים, כלי הבדיקה מוחק את התיבה.
השאר את הלקוח קטן וניתן להזרקה. מודול אחד עוטף את ארבע הקריאות; הבדיקה תלויה במודול הזה, ולעולם לא ב-HTTP גולמי שמפוזר במערך. זה מאפשר להחליף בתחליף בבדיקות יחידה ולהפנות את אותו מערך לספק אחר בלי לשכתב הצהרות.
ב-CI, פרטי ההתחברות שייכים למאגר הסודות של המשימה, לעולם לא למאגר הקוד ולעולם לא לשורת יומן. תן לכל משימה או לכל עובד מקביל תיבה משלו, והקדם לכתובות שנוצרו תחילית שמזהה את ההרצה, כדי שהודעה תועה תיוחס בבדיקה. הצב את מועד התפוגה של הלקוח מתחת למועד של המשימה עצמה, כדי שסקירה תקועה תיכשל בהודעה ברורה במקום בביטול פתאומי של המשימה.
נסה שוב את הקריאה, לא את כל התהליך. אם הקוד עוד לא הגיע, המתן וקרא שוב; הרצה חוזרת של ההרשמה תייצר הודעה שנייה ואיתה מועמד שני להצהרה. והרחק את API של התיבה מתהליכי ייצור: זו תשתית בדיקה, ומערך לעולם לא אמור להיות מסוגל לשלוח ממנה ללקוח אמיתי.
התהליך סביב הקוד, ולא המכניקה של קריאתו, מכוסה בבדיקת תהליך אימות הדואר, ושלב הפענוח במיוחד הוא הנושא של בדיקות OTP במערכי בדיקה מקצה לקצה.
בידוד וניקוי
כתובת אחת לכל מקרה היא הכלל שמונע את רוב הכשלים בין בדיקות. הוא מסיר את הצורך לחשוב איזו הודעה שייכת למי, והוא מעלים את שאלת הטריות, כי התיבה קיבלה אי פעם רק את התנועה של מקרה אחד.
הניקוי צריך להיות מפורש ובלתי מותנה. מחק את התיבה בפירוק שרץ בין אם המקרה עבר ובין אם נכשל, לא רק במסלול המאושר. הסתמכות על משך החיים של הספק בלבד היא טעות: ההודעה עשויה להישאר מספיק זמן כדי שהרצה מאוחרת על אותה מכונה תקרא אותה, ומשך החיים הזה הוא נוחות, לא הבטחה.
אם הניקוי נכשל, רשום אותו ביומן ותן למערך להסתיים. שגיאת ניקוי ראויה להיות ידועה, אבל היא אינה אותו דבר כמו פגם במוצר, וגרימת כישלון ההרצה בגללה מלמדת את הצוות להתעלם מכשלי פירוק. התייחס לכל מה שהכתובת קיבלה כאל נתוני בדיקה: הוא קיים בשביל הצהרה אחת, אין לייצא או לשתף אותו, ואסור להתייחס אליו כאל נקודת קשר של מישהו.
מגבלות והסתייגויות
API של תיבה הוא עדיין תלות של צד שלישי, ומגבלותיו הופכות לשלך. מגבלות קצב לדקה עשויות לדחות רצף יצירות מהרצה מקבילה גדולה. מכסות מגבילות כמה כתובות קיימות בעת ובעונה אחת. הודעות עשויות להתעכב, והודעה מעוכבת נראית בדיוק כמו הודעה חסרה עד שהיא מגיעה.
גם תחומים חד-פעמיים חסומים באופן נרחב. הדומיין של ספק עשוי להידחות על ידי טופס ההרשמה שאתה בודק, מה שהופך בדיקה לגיטימית לכשל מבלבל. כשזה קורה, התשובה אינה לעשות חריג עבור הספק, אלא להבין אם המוצר הנבדק דוחה כתובות חד-פעמיות בכוונה, ואז לבדוק את ההתנהגות הזו במכוון.
הסיכום הכנה הוא ש-API של התיבה הוא הכלי הנכון להצהיר על מה שמגיע. כדי להצהיר על מה שהיישום שלך פולט, קצה קבלה מקומי מהיר יותר ואין לו מכסה. רוב המערכים הבוגרים משתמשים בשניהם: לכידה מקומית לרוב ההצהרות, ו-API של תיבה רק במקום שבו נתיב המסירה האמיתי הוא הדבר הנבדק.
צעדים הבאים
מצא בדיקה אחת במערך שקוראת קוד על ידי סקירת תיבה משותפת, והחלף אותה בכלי בדיקה שיוצר כתובת טרייה מ-API של תיבה. רשום את הכתובת עם ההרצה, מחק אותה בפירוק, וראה כמה מחוסר היציבות שקיבלת על עצמך פשוט מפסיק לקרות. כשאתה צריך תיבה אמיתית ביד, עמוד הדואר הזמני מפיק אחת ברגע, והכתובות שהוא מחלק הן פיגום להרצה, לעולם לא זהות אמיתית.