बड़े टेस्ट की स्थिरता

मोबाइल ऐप्लिकेशन और फ़्रेमवर्क के साथ-साथ काम करने की सुविधा, अक्सर भरोसेमंद और बार-बार किए जा सकने वाले टेस्ट लिखने में मुश्किल बनाती है. जब कोई उपयोगकर्ता इवेंट इंजेक्ट किया जाता है, तो टेस्टिंग फ़्रेमवर्क को ऐप्लिकेशन के उस पर प्रतिक्रिया देने का इंतज़ार करना पड़ता है. इसमें स्क्रीन पर कुछ टेक्स्ट बदलने से लेकर, किसी गतिविधि को पूरी तरह से फिर से बनाने तक की प्रक्रिया शामिल हो सकती है. जब किसी टेस्ट का व्यवहार तय नहीं होता, तो उसे अमान्य माना जाता है.

Compose या Espresso जैसे आधुनिक फ़्रेमवर्क, टेस्टिंग को ध्यान में रखकर डिज़ाइन किए गए हैं. इसलिए, यह गारंटी होती है कि अगली टेस्ट ऐक्शन या एश्योरेशन से पहले, यूज़र इंटरफ़ेस (यूआई) आइडल रहेगा. इसे सिंक करना कहते हैं.

सिंक करने की सुविधा की जांच करना

टेस्ट के लिए अनजान एसिंक्रोनस या बैकग्राउंड ऑपरेशन चलाने पर भी समस्याएं आ सकती हैं. जैसे, किसी डेटाबेस से डेटा लोड करना या अनलिमिटेड ऐनिमेशन दिखाना.

पहली इमेज: सिंक करने की जांच करना.

अपने टेस्ट सुइट की भरोसेमंदता बढ़ाने के लिए, बैकग्राउंड में चलने वाली प्रोसेस को ट्रैक करने का कोई तरीका इंस्टॉल किया जा सकता है. जैसे, Espresso Idling Resources. इसके अलावा, टेस्टिंग वर्शन के लिए ऐसे मॉड्यूल भी बदले जा सकते हैं जिनके लिए, कोई क्वेरी की जा सकती है या सिंक करने की सुविधा को बेहतर बनाया जा सकता है. जैसे, कोरोटिन के लिए TestDispatcher या RxJava के लिए RxIdler.

चेतावनी: आपको अपने टेस्ट को किसी तय समय (स्लीप) के लिए रोकने से बचना चाहिए, ताकि ऐप्लिकेशन सही तरीके से काम कर सके. इससे टेस्ट ज़रूरत से ज़्यादा धीमे या अमान्य हो जाते हैं, क्योंकि एक ही टेस्ट को अलग-अलग एनवायरमेंट में चलाने के लिए, ज़्यादा या कम समय लग सकता है.

दूसरी इमेज: टेस्ट में sleep का इस्तेमाल करने से, टेस्ट धीमे या अमान्य हो जाते हैं.

ऐप्लिकेशन को क्रैश या हैंग होने से बचाने के तरीके

बड़े टेस्ट एक ही समय पर कई तरह के रेग्रेशन का पता लगा सकते हैं, क्योंकि ये किसी ऐप्लिकेशन के कई कॉम्पोनेंट की जांच करते हैं. आम तौर पर, ये टेस्ट एमुलेटर या डिवाइसों पर चलते हैं. इसका मतलब है कि इनमें ज़्यादा सटीक जानकारी मिलती है. बड़े एंड-टू-एंड टेस्ट, पूरी कवरेज देते हैं. हालांकि, इनमें कभी-कभी गड़बड़ियां हो सकती हैं.

ऐप्लिकेशन के क्रैश होने की समस्या को कम करने के लिए, ये मुख्य तरीके अपनाए जा सकते हैं:

• डिवाइसों को सही तरीके से कॉन्फ़िगर करना
• सिंक करने से जुड़ी समस्याओं से बचना
• फिर से कोशिश करने की सुविधा लागू करना

Compose या Espresso का इस्तेमाल करके बड़े टेस्ट बनाने के लिए, आम तौर पर अपनी कोई एक गतिविधि शुरू की जाती है और उपयोगकर्ता की तरह नेविगेट किया जाता है. साथ ही, यह पुष्टि की जाती है कि एश्योरमेंट या स्क्रीनशॉट टेस्ट का इस्तेमाल करके, यूज़र इंटरफ़ेस सही तरीके से काम कर रहा है या नहीं.

यूआई ऑटोमेट जैसे अन्य फ़्रेमवर्क, ज़्यादा काम करने की अनुमति देते हैं. इसकी वजह यह है कि इनकी मदद से, सिस्टम यूज़र इंटरफ़ेस (यूआई) और अन्य ऐप्लिकेशन के साथ इंटरैक्ट किया जा सकता है. हालांकि, यूज़र इंटरफ़ेस ऑटोमेटर्स की जांच के लिए, मैन्युअल तरीके से सिंक करने की ज़्यादा ज़रूरत पड़ सकती है. इसलिए, इन पर भरोसा करना मुश्किल होता है.

ध्यान दें: तीसरे पक्ष के कई टेस्टिंग फ़्रेमवर्क, टेस्ट चलाने के लिए UI Automator का इस्तेमाल करते हैं. इसलिए, इन पर भी यही सिद्धांत लागू होते हैं. यूज़र इंटरफ़ेस (यूआई) टेस्ट बनाने के लिए, Espresso और Compose Test API का इस्तेमाल करें.

डिवाइसों को कॉन्फ़िगर करना

सबसे पहले, अपने टेस्ट की भरोसेमंदता को बेहतर बनाने के लिए, आपको यह पक्का करना होगा कि डिवाइस का ऑपरेटिंग सिस्टम, टेस्ट के दौरान अचानक रुकावट न डाले. उदाहरण के लिए, जब दूसरे ऐप्लिकेशन के ऊपर सिस्टम अपडेट डायलॉग दिखता है या डिस्क में स्टोरेज कम होता है.

डिवाइस फ़ार्म की सेवा देने वाली कंपनियां, अपने डिवाइसों और एमुलेटर को कॉन्फ़िगर करती हैं, ताकि आम तौर पर आपको कोई कार्रवाई न करनी पड़े. हालांकि, खास मामलों के लिए उनके पास कॉन्फ़िगरेशन के अपने निर्देश हो सकते हैं.

Gradle से मैनेज किए जाने वाले डिवाइस

अगर एमुलेटर को खुद मैनेज किया जाता है, तो Gradle से मैनेज किए जाने वाले डिवाइसों का इस्तेमाल करके यह तय किया जा सकता है कि टेस्ट चलाने के लिए किन डिवाइसों का इस्तेमाल करना है:

android {
  testOptions {
    managedDevices {
      localDevices {
        create("pixel2api30") {
          // Use device profiles you typically see in Android Studio.
          device = "Pixel 2"
          // Use only API levels 27 and higher.
          apiLevel = 30
          // To include Google services, use "google".
          systemImageSource = "aosp"
        }
      }
    }
  }
}

इस कॉन्फ़िगरेशन के साथ, यह कमांड एक इम्यूलेटर इमेज बनाएगा, एक इंस्टेंस शुरू करेगा, टेस्ट चलाएगा, और उसे बंद कर देगा.

./gradlew pixel2api30DebugAndroidTest

Gradle की मदद से मैनेज किए जा रहे डिवाइसों में, डिवाइस के डिसकनेक्ट होने और अन्य सुधारों की स्थिति में फिर से कोशिश करने के लिए, मेकेनिज्म मौजूद होते हैं.

सिंक करने से जुड़ी समस्याओं से बचना

बैकग्राउंड या असाइनोक्रोनस तरीके से काम करने वाले कॉम्पोनेंट की वजह से, टेस्ट में गड़बड़ियां हो सकती हैं. ऐसा इसलिए होता है, क्योंकि यूज़र इंटरफ़ेस (यूआई) के तैयार होने से पहले ही टेस्ट स्टेटमेंट को लागू कर दिया जाता है. टेस्ट के दायरे के बढ़ने के साथ, गड़बड़ी होने की संभावना बढ़ जाती है. सिंक करने से जुड़ी ये समस्याएं, गड़बड़ियों का मुख्य सोर्स होती हैं. इसकी वजह यह है कि टेस्ट फ़्रेमवर्क को यह पता लगाना होता है कि कोई गतिविधि लोड हो गई है या नहीं या उसे ज़्यादा इंतज़ार करना होगा.

चेतावनी: स्लीप मोड के लिए मनमुताबिक निर्देश जोड़ने से बचना चाहिए, क्योंकि इससे जांच करने में ज़्यादा समय लगता है और गड़बड़ियां ठीक नहीं होतीं.

समाधान

Espresso के आइडलिंग रिसोर्स का इस्तेमाल करके, यह पता लगाया जा सकता है कि कोई ऐप्लिकेशन कब व्यस्त है. हालांकि, हर असाइनोक्रोनस ऑपरेशन को ट्रैक करना मुश्किल होता है. ऐसा खास तौर पर, बहुत बड़े एंड-टू-एंड टेस्ट में होता है. साथ ही, जांचे जा रहे कोड को गड़बड़ा किए बिना, आइडलिंग रिसॉर्स को इंस्टॉल करना मुश्किल हो सकता है.

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

Compose में, अलग-अलग मैचर के इंतज़ार के लिए, ComposeTestRule के हिस्से के तौर पर टेस्टिंग एपीआई का कलेक्शन होता है:

fun waitUntilAtLeastOneExists(matcher: SemanticsMatcher, timeout: Long = 1000L)

fun waitUntilDoesNotExist(matcher: SemanticsMatcher, timeout: Long = 1000L)

fun waitUntilExactlyOneExists(matcher: SemanticsMatcher,  timeout: Long = 1000L)

fun waitUntilNodeCount(matcher: SemanticsMatcher, count: Int, timeout: Long = 1000L)

साथ ही, एक सामान्य एपीआई, जो बूलियन वैल्यू दिखाने वाला कोई भी फ़ंक्शन लेता है:

fun waitUntil(timeoutMillis: Long, condition: () -> Boolean): Unit

इस्तेमाल का उदाहरण:

composeTestRule.waitUntilExactlyOneExists(hasText("Continue")</code>)</p></td>

अहम जानकारी: छोटे यूज़र इंटरफ़ेस (यूआई) टेस्ट में ज़रूरत पड़ने पर, आइडलिंग रिसॉर्स का इस्तेमाल करें. साथ ही, बड़े यूज़र इंटरफ़ेस (यूआई) टेस्ट में, एपीआई के उपलब्ध होने तक इंतज़ार करें.

फिर से कोशिश करने के तरीके

आपको गड़बड़ियों वाली जांचों को ठीक करना चाहिए. हालांकि, कभी-कभी ऐसी स्थितियां होती हैं जिनकी वजह से जांच पूरी नहीं हो पाती हैं. ये स्थितियां इतनी असंभावित होती हैं कि उन्हें दोहराना मुश्किल होता है. आपको हमेशा उन टेस्ट पर नज़र रखनी चाहिए जो काम नहीं कर रहे हैं और उन्हें ठीक करना चाहिए. हालांकि, फिर से कोशिश करने की सुविधा से डेवलपर की प्रोडक्टिविटी बनाए रखने में मदद मिल सकती है. इसके लिए, टेस्ट को तब तक चलाया जाता है, जब तक वह पास नहीं हो जाता.

समस्याओं से बचने के लिए, कई लेवल पर फिर से कोशिश करनी पड़ती है. जैसे:

• डिवाइस से कनेक्ट होने में समय लगना या कनेक्ट न होना
• एक टेस्ट फ़ेल होना

फिर से कोशिश करने की सुविधा को इंस्टॉल या कॉन्फ़िगर करना, आपके टेस्टिंग फ़्रेमवर्क और इन्फ़्रास्ट्रक्चर पर निर्भर करता है. हालांकि, आम तौर पर इन तरीकों का इस्तेमाल किया जाता है:

• JUnit का एक नियम, जो किसी भी टेस्ट को कई बार दोहराता है
• आपके सीआई वर्कफ़्लो में, फिर से कोशिश करने की कार्रवाई या चरण
• एमुलेटर के काम न करने पर उसे रीस्टार्ट करने वाला सिस्टम. जैसे, Gradle से मैनेज किए जाने वाले डिवाइस.

अहम जानकारी: बड़े टेस्ट में, दोबारा कोशिश करने की सुविधा जोड़ें. हालांकि, हमेशा ऐसे टेस्ट ठीक करें जो काम न कर रहे हों.