दूसरा एपिसोड: म्यूनिख में वासिली का गाना (मई 2019)
पिछले एपिसोड
फ़्लेकी टेस्ट Chrome में होने वाली एक आम समस्या है. इनसे दूसरे डेवलपर की उत्पादकता पर असर पड़ता है और समय के साथ ये बंद हो जाते हैं. बंद किए गए टेस्ट का मतलब है, टेस्ट कवरेज को कम करना.
प्राथमिकता तय करने का चरण
डायरेक्ट्री के मालिक, अपने कम होने वाले टेस्ट को ठीक करने की ज़िम्मेदारी लेते हैं. अगर आपको किसी अस्थिर टेस्ट के बारे में कोई गड़बड़ी मिलती है, तो कुछ मिनट का समय दें और टिप्पणी करें कि गड़बड़ी में क्या गड़बड़ी हुई. अगर आपका टेस्ट पुराना है और आपको नहीं पता कि क्या गड़बड़ी हुई है, तो टेस्ट को फिर से चालू करने की कोशिश करें. अगर साफ़ तौर पर किसी दूसरे कॉम्पोनेंट में कोई समस्या है, तो जल्द से जल्द बग को फिर से असाइन करें. उस कॉम्पोनेंट के मालिकों को गड़बड़ी के बारे में बेहतर फ़ैसला लेना चाहिए.
डीबगिंग स्टेज
कई कमांड-लाइन फ़्लैग, गड़बड़ी वाले टेस्ट को ठीक करने में मदद करते हैं. उदाहरण के लिए, --enable-pixel-output-in-tests असल ब्राउज़र यूज़र इंटरफ़ेस (यूआई) को रेंडर करेगा.
अगर डीबगर गड़बड़ी को हटा देता है, तो फ़ॉलबैक टूल इस्तेमाल करें. यह
मुमकिन है कि डीबगर के तहत, टेस्ट कभी भी गड़बड़ न हो. ऐसी स्थिति में, लॉग
स्टेटमेंट या base::debug::StackTrace काम आ सकता है.
प्रोडक्शन कोड में मौजूद गड़बड़ियों के अलावा, EXPECT__* की गड़बड़ी होने की सामान्य वजहें
ध्यान रखें:
- गलत उम्मीदें (उदाहरण के लिए, सुरक्षित पेज का मतलब एचटीटीपीएस है; इसे लोकलहोस्ट माना जा सकता है).
- टेस्ट की वजह से दौड़ की स्थितियां, सही इवेंट का इंतज़ार नहीं कर रही हैं.
[लागू करने की प्रक्रिया की जांच न करें][not- जोड़ना], बल्कि व्यवहार की जांच करें.
// It takes 2 round trips between the UI and the background thread to complete.
SyncWithTheStore();
SyncWithTheStore();
CheckTheStore();
आने वाले समय में, दो राउंड ट्रिप को तीन में बदला जा सकता है. इस वजह से, टेस्ट में कोई गड़बड़ी नहीं होगी. हालांकि, सिर्फ़ स्टोर का स्टेटस ही काम का होता है. इसके बजाय, स्टोर के लिए ऑब्ज़र्वर का इस्तेमाल करें.
इस तरह के सामान्य पैटर्न से सावधान रहें:
Submit TestPasswordForm(); // Wait until things settle down. RunLoop().RunUntilIdle(); CheckCredentialPromptVisible();
ब्राउज़र टेस्ट से, ऊपर दिया गया स्निपेट करीब-करीब गलत है. कुछ यूज़र इंटरफ़ेस (यूआई) दिखने से पहले, अलग-अलग प्रोसेस और थ्रेड में कई इवेंट होने चाहिए.
यह सही समाधान है:
SubmitTestPasswordForm(); WaitUntilCredentialPromptVisible();
ऊपर दी गई समस्या इस बात को ध्यान में रखते हुए सही है कि
WaitUntilCredentialPromptVisible() असल में यूज़र इंटरफ़ेस (यूआई) की जांच नहीं करता.
ब्राउज़र की जांचों को बाहरी यूज़र इंटरफ़ेस (यूआई) इवेंट पर निर्भर नहीं होना चाहिए, जैसे कि "फ़ोकस खो गया" या "विंडो को फ़ोरग्राउंड में ले जाया गया". एक ऐसे तरीके के बारे में सोचिए जहां प्रॉम्प्ट सिर्फ़ तब दिखता है,
जब ब्राउज़र विंडो चालू हो. इस तरह का लागू करना सही होगा; हालांकि, वास्तविक विंडो की जांच करने से टेस्ट में कुछ गड़बड़ी हो जाती है.
पोस्ट-फ़िक्स स्टेज
जांच ठीक हो जाने के बाद, इसे स्थानीय रूप से सैकड़ों बार चलाएं. Flakness पोर्टल पर नज़र बनाए रखें.