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

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

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

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

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

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

Android में जांच के प्रकार

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

विषय

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

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

दायरा

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

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

पहली इमेज: किसी सामान्य ऐप्लिकेशन में टेस्ट के दायरे.

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

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

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

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

दूसरी इमेज: टेस्ट के टाइप, उनके चलने की जगह के हिसाब से अलग-अलग होते हैं.

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

• बड़ा स्थानीय टेस्ट: Robolectric जैसे स्थानीय तौर पर चलने वाले Android सिम्युलेटर का इस्तेमाल किया जा सकता है.
• छोटा इंस्ट्रुमेंटेड टेस्ट: यह पुष्टि की जा सकती है कि आपका कोड, 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()))

लिखने के लिए यूज़र इंटरफ़ेस (यूआई)

// 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)

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

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

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

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

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

डेटा को अलग करने के तरीके

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

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

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

अगले चरण

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

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