Android ऐप्लिकेशन की टेस्टिंग से जुड़ी बुनियादी बातें

इस पेज पर, Android ऐप्लिकेशन की टेस्टिंग के मुख्य सिद्धांतों के बारे में बताया गया है. इसमें टेस्टिंग के सबसे सही तरीके और उनके फ़ायदे भी शामिल हैं.

जांच के फ़ायदे

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

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

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

Android में टेस्ट के टाइप

मोबाइल ऐप्लिकेशन जटिल होते हैं और उन्हें कई तरह के एनवायरमेंट में ठीक से काम करना चाहिए. इसलिए, कई तरह के टेस्ट होते हैं.

विषय

उदाहरण के लिए, विषय के हिसाब से अलग-अलग तरह के टेस्ट होते हैं:

  • फ़ंक्शन की जांच: क्या मेरा ऐप्लिकेशन उम्मीद के मुताबिक काम करता है?
  • परफ़ॉर्मेंस की जांच: क्या यह तेज़ी से और बेहतर तरीके से काम करता है?
  • सुलभता की जांच: क्या यह सुलभता सेवाओं के साथ ठीक से काम करता है?
  • साथ काम करने की जांच: क्या यह हर डिवाइस और एपीआई लेवल पर अच्छी तरह से काम करता है?

दायरा

टेस्ट, साइज़ या आइसोलेशन की डिग्री के हिसाब से भी अलग-अलग होते हैं:

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

टेस्ट को कई तरीकों से कैटगरी में बांटा जा सकता है. हालांकि, ऐप्लिकेशन डेवलपर के लिए सबसे अहम अंतर यह है कि टेस्ट कहां चलाए जाते हैं.

इंस्ट्रुमेंटेड टेस्ट बनाम लोकल टेस्ट

Android डिवाइस या किसी दूसरे कंप्यूटर पर टेस्ट चलाए जा सकते हैं:

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

सभी यूनिट टेस्ट लोकल नहीं होते हैं. साथ ही, सभी एंड-टू-एंड टेस्ट किसी डिवाइस पर नहीं चलते हैं. उदाहरण के लिए:

  • लोकल लेवल पर बड़े पैमाने पर टेस्ट करना: इसके लिए, लोकल लेवल पर काम करने वाले Android सिम्युलेटर का इस्तेमाल किया जा सकता है. जैसे, Robolectric.
  • छोटा इंस्ट्रुमेंटेड टेस्ट: इससे यह पुष्टि की जा सकती है कि आपका कोड, SQLite डेटाबेस जैसी फ़्रेमवर्क सुविधा के साथ अच्छी तरह से काम करता है या नहीं. इस टेस्ट को कई डिवाइसों पर चलाया जा सकता है, ताकि SQLite के कई वर्शन के साथ इंटिग्रेशन की जांच की जा सके.

उदाहरण

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

एस्प्रेसो

// When the Continue button is clicked
onView(withText("Continue"))
    .perform(click())

// Then the Welcome screen is displayed
onView(withText("Welcome"))
    .check(matches(isDisplayed()))

Compose यूज़र इंटरफ़ेस (यूआई)

// When the Continue button is clicked
composeTestRule.onNodeWithText("Continue").performClick()

// Then the Welcome screen is displayed
composeTestRule.onNodeWithText("Welcome").assertIsDisplayed()

इस स्निपेट में, ViewModel के लिए यूनिट टेस्ट का एक हिस्सा दिखाया गया है (लोकल, होस्ट की ओर से किया जाने वाला टेस्ट):

// Given an instance of MyViewModel
val viewModel = MyViewModel(myFakeDataRepository)

// When data is loaded
viewModel.loadData()

// Then it should be exposing data
assertTrue(viewModel.data != null)

टेस्ट किया जा सकने वाला आर्किटेक्चर

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

जिस आर्किटेक्चर की जांच नहीं की जा सकती उससे ये समस्याएं होती हैं:

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

आर्किटेक्चर से जुड़े दिशा-निर्देशों के बारे में ज़्यादा जानने के लिए, ऐप्लिकेशन आर्किटेक्चर की गाइड देखें.

डिकपलिंग के तरीके

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

डिकपलिंग की सामान्य तकनीकों में ये शामिल हैं:

  • किसी ऐप्लिकेशन को प्रज़ेंटेशन, डोमेन, और डेटा जैसी लेयर में बांटें. किसी ऐप्लिकेशन को मॉड्यूल में भी बांटा जा सकता है. हर सुविधा के लिए एक मॉड्यूल होता है.
  • ऐसी इकाइयों में लॉजिक जोड़ने से बचें जो गतिविधियों और फ़्रैगमेंट जैसी बड़ी डिपेंडेंसी पर निर्भर करती हैं. इन क्लास को फ़्रेमवर्क के एंट्री पॉइंट के तौर पर इस्तेमाल करें. साथ ही, यूज़र इंटरफ़ेस (यूआई) और कारोबारी नियम को कहीं और ले जाएं, जैसे कि Composable, ViewModel या डोमेन लेयर पर.
  • कारोबारी नियम वाली क्लास में, सीधे तौर पर फ़्रेमवर्क डिपेंडेंसी का इस्तेमाल करने से बचें. उदाहरण के लिए, ViewModels में Android कॉन्टेक्स्ट का इस्तेमाल न करें.
  • डिपेंडेंसी को बदलना आसान बनाएं. उदाहरण के लिए, कॉन्क्रीट इंप्लिमेंटेशन के बजाय इंटरफ़ेस का इस्तेमाल करें. डिपेंडेंसी इंजेक्शन का इस्तेमाल करें, भले ही डीआई फ़्रेमवर्क का इस्तेमाल न किया जा रहा हो.

अगले चरण

अब आपको पता है कि आपको टेस्ट क्यों करना चाहिए और टेस्ट के दो मुख्य टाइप कौनसे हैं. इसलिए, क्या टेस्ट करना है लेख पढ़ें या टेस्ट करने की रणनीतियों के बारे में जानें

इसके अलावा, अगर आपको अपना पहला टेस्ट बनाना है और उसे करके सीखना है, तो टेस्टिंग कोडलैब देखें.