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

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

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

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

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

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

स्थिरता को बेहतर करने के तरीके

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

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

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

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

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

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

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

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

ऐसे डिवाइस जिन्हें 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 से मैनेज किए जाने वाले डिवाइस.