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