ईमेल परीक्षण का अविश्वसनीय संस्करण संक्षिप्त है: एक पता बनाएं, पाँच सेकंड के लिए स्लीप करें, पहला संदेश पढ़ें, और आशा करें कि वह इस रन से संबंधित है।
विश्वसनीय संस्करण अभी भी सरल है, लेकिन यह डिलीवरी को असिंक्रोनस मानता है। यह एक अद्वितीय पता बनाता है, प्रारंभ समय रिकॉर्ड करता है, डेडलाइन के भीतर पोल करता है, इच्छित संदेश से मेल खाता है, उत्पाद क्रिया को सत्यापित करता है, और जब कुछ विफल होता है तो पर्याप्त संदर्भ रिपोर्ट करता है.
API कुंजी को URL में न रखें
GPTMail कुंजी को X-API-Key हेडर में भेजें। इसे ?api_key= क्वेरी पैरामीटर में न रखें। URLs अक्सर ब्राउज़र इतिहास, एक्सेस लॉग, मॉनिटरिंग सिस्टम और रेफ़रर डेटा में संग्रहीत होते हैं.
X-API-Key: YOUR_API_KEYकुंजी को अपने CI सीक्रेट मैनेजर में संग्रहीत करें और लॉग में मास्क करें। अन्वेषण के लिए सार्वजनिक दैनिक कुंजी सुविधाजनक है; नियंत्रित ऑटोमेटेड सूट्स को ऐसी कुंजी का उपयोग करना चाहिए जिसकी कोटा और उपयोग आप ट्रैक कर सकें.
वर्तमान एंडपॉइंट्स और प्रतिक्रिया उदाहरण GPTMail API दस्तावेज़ पृष्ठ पर रखे गए हैं.
प्रत्येक रन के लिए एक पता
प्रत्येक स्वतंत्र रूप से चलने वाले परीक्षण के लिए नया पता उत्पन्न करें। पूरे परीक्षण सूट द्वारा साझा किए गए इनबॉक्स से सहीपन न निकालें.
पता, परिदृश्य ID, पर्यावरण, और परीक्षण प्रारंभ समय रिकॉर्ड करें। ये मान आपको पुरानी संदेशों को अस्वीकार करने और टकरावों का निदान करने में मदद करते हैं, बिना संदेश रहस्य लॉग किए.
निश्चित स्लीप के बजाय डेडलाइन के विरुद्ध पोल करें
ईमेल डिलीवरी समय बदलता रहता है। एक निश्चित पाँच‑सेकंड स्लीप तेज़ डिलीवरी पर बर्बादी है और धीमी डिलीवरी पर अस्थिर.
एक सीमित लूप का उपयोग करें:
deadline = now + 90 seconds
delay = 2 seconds
while now < deadline:
messages = list inbox
candidate = newest message matching sender, subject, and start time
if candidate exists:
read candidate and continue the product test
wait delay with a small random jitter
delay = min(delay * 1.5, 10 seconds)डेडलाइन परीक्षण अनुबंध का हिस्सा है। पासवर्ड‑रीसेट प्रवाह को बल्क न्यूज़लेटर प्रीव्यू से अलग सीमा की आवश्यकता हो सकती है। सीमा को स्पष्ट रखें ताकि धीमी निर्भरता पूरी CI जॉब को चुपचाप न बढ़ा दे.
सटीक रूप से मिलान करें
“इनबॉक्स में पहला संदेश” उपयोगी चयनकर्ता नहीं है। कई संकेतों से मिलान करें:
- प्राप्तकर्ता इस रन के लिए बनाए गए पते के बराबर हो;
- निर्माण समय ट्रिगर समय से बाद का हो;
- प्रेषक अपेक्षित सेवा से संबंधित हो;
- विषय या संदेश प्रकार प्रवाह से मेल खाता हो;
- संदेश ID पहले से उपयोग नहीं किया गया हो।
जब प्रेषक कई कोड जारी कर सकता है, तो नवीनतम मेल खाने वाला संदेश चुनें। उसके ID को परीक्षण आउटपुट में संरक्षित रखें ताकि पुनः प्रयास अनजाने में उसे पुनः उपयोग न कर सके.
सूची मिलान के बाद ही पढ़ें
इनबॉक्स सूचीकरण सस्ता खोज चरण होना चाहिए। केवल चयनित उम्मीदवार के लिए पूर्ण संदेश प्राप्त करें। इससे अनावश्यक कार्य कम होता है और असंबंधित प्रोमोशनल मेल को पार्स करने से बचा जाता है.
व्यवसायिक परिणाम को सत्यापित करें, न कि केवल छह-अंकीय स्ट्रिंग की उपस्थिति को। कोड सबमिट करें या अपेक्षित लिंक खोलें, फिर पुष्टि करें कि खाता सही स्थिति तक पहुंचता है.
दर सीमा को संकेत के रूप में संभालें
यदि API कोटा या रेट‑लिमिट प्रतिक्रिया देता है, तो वर्तमान प्रयास को रोकें और रीसेट जानकारी प्रदर्शित करें। आक्रामक पुनः प्रयास स्पष्ट क्षमता संकेत को शोर में बदल देते हैं और असंबंधित परीक्षणों को विलंबित कर सकते हैं.
टेस्ट रनर में समवर्तीता को सीमित करें, विशेषकर जब एक सूट एक साथ कई पते बनाता है। छोटे वर्कर पूल को सैकड़ों समकालिक पोलिंग लूप की तुलना में डिबग करना आसान होता है.
विफलताओं को छुपाए बिना सफ़ाई करें
सफ़ाई को प्रमाण एकत्रित होने के बाद चलना चाहिए। सफलता पर, संदेश हटाएँ या छोटे रिटेंशन को उन्हें संभालने दें। विफलता पर, पता और संदेश ID को संरक्षित CI आर्टिफैक्ट्स में पर्याप्त समय तक रखें, फिर उन्हें हटाएँ.
कभी भी सत्यापन कोड, निजी लिंक, या पूर्ण HTML बॉडी को सार्वजनिक बिल्ड लॉग में प्रिंट न करें.
पुनः प्रयास को आइडेम्पोटेंट बनाएं
परीक्षण को नए पते के साथ नई रन के रूप में पुनः प्रयास करें। यह न मानें कि समान अनुरोध को समान खाते और इनबॉक्स पर दोहराने से साफ़ स्थिति से शुरू होता है। प्रेषक पुराने कोड को अमान्य कर सकता है, दोहराए गए अनुरोधों को थ्रॉटल कर सकता है, या डुप्लिकेट निमंत्रणों को अस्वीकार कर सकता है.
यदि नेटवर्क अनुरोध टाइम‑आउट हो जाता है, तो “कोई प्रतिक्रिया नहीं मिली” और “ऑपरेशन नहीं हुआ” में अंतर करें। विनाशकारी पुनः प्रयास करने से पहले देखी जा सकने वाली स्थिति की जाँच करें.
विफलता बिंदु की रिपोर्ट करें
एक उपयोगी ऑटोमेशन विफलता इन चरणों में से एक को पहचानती है:
- पता निर्माण विफल रहा;
- ईमेल कतार में डालने से पहले उत्पाद क्रिया विफल रही;
- डेडलाइन से पहले कोई मेल खाने वाला संदेश नहीं आया;
- संदेश आया लेकिन सामग्री मेल नहीं खाई;
- सत्यापन क्रिया विफल रही;
- सफ़ाई विफल रही।
यह वर्गीकरण एक अस्थायी “ईमेल परीक्षण विफल” को टीम द्वारा संभाले जाने वाले कार्य में बदल देता है.
बड़े परीक्षण मैट्रिक्स के लिए, पढ़ें एक वास्तविक ईमेल परीक्षण योजना। डिलीवरी निदान के लिए, उपयोग करें सत्यापन ईमेल नहीं पहुँच रहा है: टूटे हुए चरण को खोजें।