Compose टेस्ट में आइडलिंग रिसॉर्स के विकल्प: waitUntil एपीआई (अपडेट किया गया)

इस लेख में, Compose में waitUntil टेस्ट एपीआई का इस्तेमाल करने का तरीका बताया गया है. इससे कुछ शर्तों के पूरा होने तक इंतज़ार किया जा सकता है. कुछ मामलों में, आइडलिंग रिसॉर्स का इस्तेमाल करने के बजाय इसका इस्तेमाल करना बेहतर होता है.

[2023 का अपडेट] खास जानकारी: Compose टेस्ट (v1.4.0+) में सिंक करने के लिए, नए waitUntil एपीआई का इस्तेमाल करें.

सिंक करने की सुविधा क्या है?

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

इमेज को फ़ुल साइज़ में देखने के लिए, Enter दबाएं या क्लिक करें

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

इमेज को फ़ुल साइज़ में देखने के लिए, Enter दबाएं या क्लिक करें

androidx.test और Compose Test, कुछ ऐसे तरीके इस्तेमाल करते हैं जिनकी वजह से आपको इस बारे में ज़्यादा चिंता करने की ज़रूरत नहीं पड़ती. उदाहरण के लिए, अगर मुख्य थ्रेड व्यस्त है, तो टेस्ट तब तक रुक जाता है, जब तक वह अगली लाइन को लागू नहीं कर सकता.

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

पहला विकल्प: आइडलिंग रिसॉर्स

Idling Resources, Espresso की एक सुविधा है. इसकी मदद से डेवलपर यह तय कर सकता है कि ऐप्लिकेशन कब व्यस्त है. इनका इस्तेमाल दो तरीकों से किया जा सकता है:

1. उन्हें ऐसे फ़्रेमवर्क या लाइब्रेरी में इंस्टॉल करना जो ऐसा काम कर रही है जिसे टेस्ट नहीं देख सकता.

इसका एक अच्छा उदाहरण RxIdler है, जो RxJava शेड्यूलर को रैप करता है. आइडलिंग रिसॉर्स रजिस्टर करने का यह सबसे सही तरीका है. इससे, टेस्ट कोड से टेस्ट सेटअप को अलग रखा जा सकता है.

2. टेस्ट किए जा रहे कोड में बदलाव करके, यह जानकारी साफ़ तौर पर देना कि आपका ऐप्लिकेशन व्यस्त है या नहीं.

उदाहरण के लिए, डेटा सोर्स से डेटा लोड करते समय, अपनी रिपॉज़िटरी (या टेस्ट डबल) में बदलाव करके यह दिखाया जा सकता है कि वह व्यस्त है:

यह तरीका सही नहीं है, क्योंकि इससे आपके प्रोडक्शन कोड में गड़बड़ी हो सकती है या टेस्ट डबल बनाना मुश्किल हो सकता है. साथ ही, कुछ मामलों में इन्हें इंस्टॉल करना मुश्किल होता है. उदाहरण के लिए, Kotlin फ़्लो में Idling Resources का इस्तेमाल कैसे किया जाएगा? आखिरी अपडेट कौन-सा है?

इसके बजाय, हम चीज़ों के लिए इंतज़ार कर सकते हैं.

दूसरा विकल्प: गलत तरीके से इंतज़ार करना

डेटा लोड होने में आम तौर पर कम समय लगता है. खास तौर पर, नकली डेटा का इस्तेमाल करते समय. इसलिए, जब टेस्ट को कुछ सेकंड के लिए स्लीप मोड में रखा जा सकता है, तो संसाधनों को निष्क्रिय रखकर समय क्यों बर्बाद करना?

इस टेस्ट को ज़रूरत से ज़्यादा समय लगेगा या यह पूरा नहीं होगा. जब आपके पास सैकड़ों या हज़ारों यूज़र इंटरफ़ेस (यूआई) टेस्ट होते हैं, तो आपको टेस्ट को जल्द से जल्द पूरा करना होता है.

इसके अलावा, कभी-कभी एम्युलेटर या डिवाइस ठीक से काम नहीं करते और अटक जाते हैं. इस वजह से, इस ऑपरेशन को पूरा होने में 2000 मि॰से॰ से ज़्यादा समय लगता है और आपकी बिल्ड प्रोसेस रुक जाती है. अगर आपके पास सैकड़ों टेस्ट हैं, तो यह एक बड़ी समस्या बन जाती है.

तीसरा विकल्प: सही तरीके से इंतज़ार करना!

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

Compose में, waitUntil फ़ंक्शन का इस्तेमाल किया जा सकता है. यह एक ऐसा फ़ंक्शन है जो एक बूलियन वैल्यू जनरेट करता है.

22/03/2023 का अपडेट: Compose 1.4.0 से, हमने waitUntil एपीआई का एक नया सेट जोड़ा है:

[Before 1.4.0: Use these helpers: waitUntilExists, waitUntilNodeCount]

…और उन्हें इस तरह इस्तेमाल करें:

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

ऐसे में, आपको इसका इस्तेमाल कब करना चाहिए? इसका सबसे अच्छा इस्तेमाल, LiveData, Kotlin Flow या RxJava की मदद से, किसी ऑब्ज़र्वेबल से डेटा लोड करना है. जब आपके यूज़र इंटरफ़ेस (यूआई) को कई अपडेट मिलते हैं, तब आपको waitUntil का इस्तेमाल करके सिंक्रनाइज़ेशन को आसान बनाना पड़ सकता है.

उदाहरण के लिए, जब किसी व्यू से फ़्लो इकट्ठा किया जाता है, तो:

इसके बाद, इसमें कई आइटम भेजे जाते हैं:

अगर repository को पहला नतीजा दिखाने में बहुत ज़्यादा समय लगता है, तो टेस्ट फ़्रेमवर्क यह मान लेगा कि “Loading” आइडल स्टेट है. यह collectAsState में असाइन की गई शुरुआती वैल्यू होती है. इसके बाद, टेस्ट फ़्रेमवर्क अगले स्टेटमेंट पर चला जाएगा.

इसलिए, अगर आपको यह पक्का करना है कि यूज़र इंटरफ़ेस (यूआई) में लोडिंग इंडिकेटर नहीं दिख रहा है, तो टेस्ट को ज़्यादा भरोसेमंद बनाया जा सकता है:

हैप्पी… थोड़ा इंतज़ार करें… टेस्टिंग!

कोड स्निपेट का लाइसेंस:

Copyright 2022 Google LLC.
SPDX-License-Identifier: Apache-2.0