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

// 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 कॉन्टेक्स्ट का इस्तेमाल न करें.
• डिपेंडेंसी को बदलना आसान बनाएं. उदाहरण के लिए, ठोस लागू करने के बजाय इंटरफ़ेस का इस्तेमाल करें. डिपेंडेंसी इंजेक्शन फ़्रेमवर्क का इस्तेमाल न करने पर भी, डिपेंडेंसी इंजेक्शन का इस्तेमाल करें.

अगले चरण

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

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