التقاط البريد في الاختبارات يعني التوقف عن معاملة البريد كشيء يغادر الجهاز. فبدل أن يدع خط الأتمتة يرسل عبر مزود عام ثم يستقصي صندوقا في العالم الخارجي، يوجه التطبيق إلى نقطة استقبال على جهاز البناء، ويقرأ الاختبار ما سلم إليها. النتيجة أسرع، وتعمل دون اتصال، ومحصنة ضد أعطال المزود التي تحول مجموعة ناجحة إلى حمراء.
لماذا يجب ألا يعتمد خط الأتمتة على مزود بريد؟
الاختبار الذي يرسل بريدا حقيقيا عبر خدمة حقيقية استورد إلى نتيجته كل ما في تلك الخدمة من هشاشة. قد تنتهي صلاحية المصادقة، وقد تستنفد الحصص، وقد يكون المزود غير متاح لحظة، ولا شيء من ذلك يقول شيئا عن كودك. والأسوأ أن هذه النتائج لا تميز عن الأعطال التي تريد اكتشافها فعلا، فيتعلم الفريق إعادة تشغيل خط الأتمتة بدل قراءته.
وهناك تكلفة ثانية يسهل إغفالها: خط الأتمتة الذي يرسل بريدا حقيقيا يجب أن يخبر إلى أين يرسله. وإن كانت تلك الوجهة عنوانا حقيقيا، فكل تشغيل يسلم حركة اختبار إلى شخص ما. أما توجيه البناء إلى نقطة محلية فيزيل السؤال كله، لأن لا شيء يغادر الشبكة.
وثمة اعتبار ثالث يتعلق بالسرعة. انتظار مزود خارجي يضيف ثواني إلى كل حالة تحتاج بريدا، وهذه الثواني تتضاعف مع كل تشغيل حتى تصبح جزءا معتبرا من زمن خط الأتمتة لا مبلغا هامشيا.
كيف تعمل نقطة الالتقاط المحلية؟
الآلية هي نفسها التي يستخدمها أي خادم بريد. يضبط التطبيق بمضيف ومنفذ خادم البريد لمدة تشغيل الاختبار. ذلك المضيف هو واجهة الحلقة المحلية، والمنفذ هو ما اختاره إطار التشغيل لهذا التشغيل، فلا تحتاج أي قيمة تهيئة إلى أن تثبت كحقيقة عن العالم.
وبمجرد أن يسلم التطبيق الرسالة، تقبلها نقطة الالتقاط وتحفظها في الذاكرة أو تكتبها إلى ملف وتتيحها للاختبار. لا شيء يرحل إلى أي مكان.
ولهذا الشكل ثلاث خصائص تجعل التحققات موثوقة:
- الرسالة موجودة قبل أن يبحث عنها الاختبار، لأن التسليم متزامن، فلا توجد حلقة استقصاء يمكن أن تخطئ.
- المحتوى دقيق، بما في ذلك الترويسات والترميز، لأن شيئا لم يعد كتابته أثناء النقل.
- الرسالة قابلة لإعادة القراءة بقدر ما يحتاج الاختبار، لأنها محفوظة لا مستهلكة.
ما الذي يوجد فعلا داخل رسالة ملتقطة؟
أكثر من المتن، والأجزاء الإضافية هي موضع التحققات المفيدة. تحمل الرسالة الملتقطة معلومات المغلف من لحظة التسليم مع الرسالة نفسها، أي أن الاختبار يستطيع فحص من تدعي الرسالة أنها منه، وإلى أي عنوان أرسلت، وسطر الموضوع، ونوع المحتوى، والمتن بالصيغة التي أنتجها تطبيقك.
وهذا مهم لأن التسليم ليس الشيء الذي يختبر. المحتوى هو. المجموعة التي تتحقق فقط من قبول الرسالة تنجح بسرور بينما يعرض القالب اسما فارغا، أو يشير الرابط إلى بيئة خاطئة.
هل ينبغي للاختبار الفاشل أن يحتفظ بالرسالة الخام؟
نعم، وينبغي أن يحتفظ بها عن قصد لا بالمصادفة. حين يفشل تحقق على المتن، فإن أنفع أثر هو الرسالة كما أنتجت فعلا. وبدونه تكون الخطوة التالية عادة إعادة إنتاج العطل يدويا على الجهاز، وهذا بالضبط العمل اليدوي الذي وجدت نقطة الالتقاط لتزيحه.
وعادتان تجعلان الأثر نافعا. أرفقه بالتشغيل الفاشل لا بموضع مشترك، حتى لا يكتب تشغيلان متوازيان فوق أحدهما الآخر. وعامله كبيانات اختبار حين تحفظه: قد تحتوي رسالة ملتقطة على عناوين وقيم مولدة من التشغيل، ويجب الاحتفاظ بها بالجدول القصير نفسه الذي يحفظ به باقي مخرجات التشغيل. والعناوين المستخدمة بهذه الطريقة موجودة للتحقق، لا كهويات حقيقية.
متى تحتاج إلى صندوق بريد حقيقي بدل ذلك؟
الالتقاط المحلي لا يستطيع الإجابة عن أسئلة تتضمن العالم الخارجي. فإن كان الاختبار يجب أن يثبت أن رسالة تنجو من مسار تسليم فعلي، أو أن منظومة طرف ثالث تتفاعل معها، فلا بد أن يغادر شيء الجهاز.
وفي تلك الحالات يكفي غالبا صندوق للتخلص: عنوان ينشأ للتشغيل، ويقرأ مرة، ويهمل. تنشئ صفحة البريد المؤقت عنوانا عند الطلب، ولأن أحدا لم يسجله يبدأ الصندوق فارغا ولا يحتوي إلا الحركة التي أثارها الاختبار. والتمييز جدير بأن يبقى واضحا في ذهنك: الالتقاط المحلي للتحقق من الذي يرسله تطبيقك، وصندوق حقيقي للتحقق من الذي يصل.
ما الذي لا يختبره الالتقاط المحلي؟
يثبت الالتقاط المحلي أن تطبيقك أنتج الرسالة الصحيحة وأرسلها إلى العنوان الصحيح، وهذا فحص قيم لكنه لا يثبت كل ما يهم عند الإطلاق. فهو لا يثبت أن الرسالة تنجو من مرشحات مزود بريد حقيقي، ولا أن نطاقك مهيأ للإرسال، ولا أن الرسالة تعرض كما تتوقعها عملاء البريد الفعليون على أجهزتهم.
ولهذا لا يغني عن فحص قليل لكنه عام. أبق فحصا واحدا أو اثنين يمران عبر مسار عام حقيقي، واستخدمهما للحقائق التي لا يستطيع الجهاز إثباتها وحدها. وأما كل ما يتكرر مع كل تغيير ويحتاج نتيجة سريعة، فمكانه نقطة الالتقاط المحلية.
والقاعدة العملية أن الاختبارين يقيسان شيئين مختلفين، ولا يحل أحدهما محل الآخر. الجهاز يجيب عن سؤال هل ينتج تطبيقنا البريد الذي قصدناه. والمسار العام يجيب عن سؤال هل يصل ذلك البريد فعلا إلى صندوق شخص. والخلط بين السؤالين هو ما يجعل الفرق يبدو زائدا عن الحاجة.
للمطورين: المنافذ والتوازي والتحققات
أربعة قرارات تحدد ما إذا بقي هذا الترتيب مملا بالمعنى الجيد.
ربط نقطة الالتقاط بواجهة الحلقة المحلية وحدها هو الأول. يحد ذلك من التعرض ويوضح أن النقطة ليست خدمة بريد لشيء خارج التشغيل. ودع المنفذ يأتي من البيئة لا من ثابت، حتى لا يتصادم تشغيلان على جهاز واحد.
عزل التشغيلات هو الثاني. أعط كل تشغيل عملية نقطة التقاط خاصة به، أو على الأقل مخزنه الخاص، وأعط كل حالة عنوان مستلم خاصا بها. فالطابور المشترك الذي تقرأه عدة اختبارات على التوازي ينتج أكثر أنماط الفشل إزعاجا: اختبارا ينجح منفردا ويفشل في خط أتمتة كامل.
التحقق من المحتوى لا من الزمن المنقضي هو الثالث. ولأن التسليم متزامن فلا شيء ينتظر، والنوم في هذا النوع من الاختبارات علامة على أن شيئا يختبر عبر الواجهة الخطأ.
الفشل الصاخب هو الرابع. حين يفشل تحقق على رسالة، اطبع الجزء الذي جرى مقارنته أو أرفقه. الاختبار الذي يبلغ عن عدم تطابق فقط دون إظهار الرسالة التي قرأها يعيد من يأتي بعده إلى إعادة الإنتاج اليدوي.
وأضف إلى القائمة تحققا لا علاقة له بالالتقاط نفسه: أن التهيئة التي تشير إليها بيئة الاختبار لا تشحن إلى الإنتاج. أشهر عطل في هذا الترتيب بيئة إنتاج ترسل بريدا حقيقيا إلى نقطة التقاط داخلية، أو العكس، وهي حالات لا يكشفها اختبار ناجح على الجهاز، لأن الجهاز لا يرى إلا ما يخصه.
وإن كان مسار الالتقاط عندك يغذي اختبارات تقرأ رموزا قصيرة بدل المتون، فإن اختبار OTP في اختبارات الطرف إلى الطرف يغطي جانب التحليل، وصندوق البريد الشامل يغطي ما تفعله حين تحتاج بيئة ما نطاقا كاملا لا نقطة واحدة.
الخطوات التالية
اعثر على الاختبار الواحد في مجموعتك الذي يرسل بريدا عبر مزود، وأحص كم مرة فشل لأسباب لا علاقة لها بالتغيير الذي تختبره. ثم أعطه نقطة محلية لتشغيل واحد وقارن. أبق المزود العام لكل ما يحتاج الإنترنت المفتوح فعلا، والباقي مكانه الجهاز الذي يشغل الاختبارات.