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)

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

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

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

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

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

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

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

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

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

अगले चरण

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

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