The Chromium Chronicle #2: फ़ाइटिंग टेस्ट फ़्लेकीनेस

एपिसोड 2: म्यूनिख में वासिली का गाना (मई, 2019)
पिछले एपिसोड

Chrome में अनियमित जांच एक आम समस्या है. वे अन्य डेवलपर की उत्पादकता पर असर पड़ता है और समय के साथ हम बंद हो जाते हैं. बंद किए गए टेस्ट का मतलब है कि टेस्ट कवरेज में कमी.

प्राथमिकता तय करने का स्टेज

डायरेक्ट्री के मालिक, अपने फ़्लेकी टेस्ट ठीक करने के लिए ज़िम्मेदार होते हैं. अगर आपको किसी फ़्लेकी टेस्ट के बारे में कोई गड़बड़ी मिली है, तो कुछ मिनट बिताएं और टिप्पणी करें कि गड़बड़ी में क्या हुआ. अगर आपका पुराना फ्लैकी टेस्ट है और इससे यह पता नहीं चलता कि क्या गड़बड़ी हुई. जांच को फिर से चालू करके देखें. अगर किसी दूसरे कॉम्पोनेंट में कोई समस्या है, तो गड़बड़ी को जल्द से जल्द फिर से असाइन करें. कॉम्पोनेंट के मालिकों को गड़बड़ी के बारे में बेहतर फ़ैसला लेना चाहिए,

डीबगिंग स्टेज

कई कमांड-लाइन फ़्लैग इन कामों के लिए काम के होते हैं की जांच कर रहा है. उदाहरण के लिए, --enable-pixel-output-in-tests असली ब्राउज़र यूज़र इंटरफ़ेस (यूआई) रेंडर करेगा.

अगर डीबगर गड़बड़ी को गायब करता है, तो फ़ॉलबैक टूल इस्तेमाल करें. यह समय है संभव है कि डीबगर में, टेस्ट कभी भी फ़्लेकी न हो. ऐसी स्थिति में, स्टेटमेंट या base::debug::StackTrace का इस्तेमाल करना आसान हो सकता है.

यह न करें

प्रोडक्शन में गड़बड़ियों के अलावा, EXPECT__* के काम न करने की आम वजहों को ध्यान में रखें कोड:

  • गलत उम्मीदें (उदाहरण के लिए, सुरक्षित पेज का मतलब एचटीटीपीएस होता है; इसके बजाय यह कोई लोकल होस्ट हो सकता है).
  • टेस्ट की वजह से रेस की शर्तें, सही इवेंट का इंतज़ार न करना.

[लागू करने की जांच न करें][लागू नहीं] लेकिन व्यवहार.

// 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() असल में यूज़र इंटरफ़ेस (यूआई) की जांच नहीं करता. ब्राउज़र के टेस्ट, बाहरी यूज़र इंटरफ़ेस (यूआई) इवेंट पर निर्भर नहीं होने चाहिए, जैसे कि "फ़ोकस खो गया है" या "विंडो फ़ोरग्राउंड में बदल गई". ऐसे इंप्लिमेंटेशन की कल्पना करें जिसमें प्रॉम्प्ट केवल ब्राउज़र विंडो के सक्रिय होने पर ही दिखाई देता है. इस तरह से लागू करना सही होगा; हालांकि, असली विंडो की जांच करने से टेस्ट में गड़बड़ी हो जाती है.

ठीक करने के बाद का स्टेज

टेस्ट ठीक हो जाने के बाद, उसे स्थानीय तौर पर सैकड़ों बार चलाएं. अपने चैनल पर इन चीज़ों का ज़्यादा से ज़्यादा इस्तेमाल करने के लिए, फ़्लेकीनेस पोर्टल.