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 या डोमेन लेयर.
• कारोबारी नियमों वाली क्लास में, सीधे तौर पर फ़्रेमवर्क की डिपेंडेंसी का इस्तेमाल न करें. उदाहरण के लिए, ViewModel में Android Context का इस्तेमाल न करें.
• डिपेंडेंसी को आसानी से बदलने की सुविधा दें. उदाहरण के लिए, कॉन्क्रीट इंप्लीमेंटेशन के बजाय interfaces का इस्तेमाल करें. अगर DI फ़्रेमवर्क का इस्तेमाल नहीं किया जा रहा है, तब भी डिपेंडेंसी इंजेक्शन का इस्तेमाल करें.

अगले चरण

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

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