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

अगले चरण

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

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