Android में टेस्ट डबल्स का इस्तेमाल करना

किसी एलिमेंट या सिस्टम के लिए टेस्टिंग की रणनीति डिज़ाइन करते समय, आपको तीन टेस्टिंग के ये पहलू:

• स्कोप: टेस्ट कितना कोड छूता है? जांच से सिर्फ़ एक यूआरएल की पुष्टि हो सकती है पूरा ऐप्लिकेशन या इन दोनों के बीच की किसी जगह का इस्तेमाल करें. कॉन्टेंट बनाने जांचा गया स्कोप अंडर टेस्ट है और आम तौर पर इसे विषय के तहत टेस्ट, हालांकि सिस्टम अंडर टेस्ट या यूनिट अंडर टेस्ट भी.
• स्पीड: टेस्ट कितनी तेज़ी से चलता है? जांच की स्पीड, मिलीसेकंड में नहीं हो सकती कुछ मिनट लग सकते हैं.
• फ़िडेलिटी: "असल दुनिया में" क्या टेस्ट है? उदाहरण के लिए, अगर कोड का हिस्सा है आपको नेटवर्क अनुरोध करने की ज़रूरत है, क्या टेस्ट कोड असल में क्या इस नेटवर्क के अनुरोध का पता चलता है या इस नतीजे की नकल की गई है? अगर यह जाँच असल में आपके खाते की को नेटवर्क से जोड़ना है, तो इसका मतलब है कि उसकी फ़िडेलिटी ज़्यादा है. समस्या यह है कि की जांच में ज़्यादा समय लग सकता है, नेटवर्क बंद होने पर गड़बड़ी हो सकती है या इस्तेमाल करना महंगा पड़ सकता है.

जांच की रणनीति तय करने का तरीका जानने के लिए, जांच करें पर जाएं.

आइसोलेशन और डिपेंडेंसी

किसी एलिमेंट या सिस्टम की जांच करते समय, उसे अलग-अलग रखते हुए टेस्ट किया जाता है. इसके लिए उदाहरण के लिए, ViewModel की जांच करने के लिए, आपको एम्युलेटर चालू करने और यूज़र इंटरफ़ेस (यूआई) लॉन्च करने की ज़रूरत नहीं होगी क्योंकि यह Android फ़्रेमवर्क पर निर्भर नहीं होता (या नहीं होना चाहिए).

हालांकि, जिस विषय की जांच की जा रही है वह दूसरे लोगों पर निर्भर कर सकता है, ताकि वह काम करे. इसके लिए उदाहरण के लिए, ViewModel काम करने के लिए डेटा रिपॉज़िटरी पर निर्भर हो सकता है.

जब आपको टेस्ट में शामिल किसी विषय पर डिपेंडेंसी देनी हो, तो एक सामान्य तरीका टेस्ट डबल (या टेस्ट ऑब्जेक्ट) बनाना है. टेस्ट डबल ऐसे ऑब्जेक्ट होते हैं आपके ऐप्लिकेशन में कॉम्पोनेंट के रूप में दिखता और काम करता है, लेकिन उन्हें आपके ऐप्लिकेशन की जांच में बनाया जाता है, ताकि कोई खास व्यवहार या डेटा दिखाती हैं. मुख्य फ़ायदे ये हैं कि ज़्यादा तेज़ी से और आसानी से टेस्ट किए जा सकते हैं.

टेस्ट डबल्स के प्रकार

टेस्ट डबल कई तरह के होते हैं:

नकली प्रॉडक्ट का इस्तेमाल करने का उदाहरण

मान लें कि आपको किसी इंटरफ़ेस पर निर्भर ViewModel की यूनिट टेस्ट करनी है इसे UserRepository कहते हैं और यह यूज़र इंटरफ़ेस (यूआई) में पहले उपयोगकर्ता के नाम को दिखाता है. आप इंटरफ़ेस को लागू करके और पहले से मौजूद डेटा शामिल है.

object FakeUserRepository : UserRepository {
    fun getUsers() = listOf(UserAlice, UserBob)
}

val const UserAlice = User("Alice")
val const UserBob = User("Bob")

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

नीचे दिए गए टेस्ट से इस बात की पुष्टि होती है कि ViewModel पहले उपयोगकर्ता को सही तरीके से एक्सपोज़र करता है दृश्य का नाम जोड़ सकते हैं.

@Test
fun viewModelA_loadsUsers_showsFirstUser() {
    // Given a VM using fake data
    val viewModel = ViewModelA(FakeUserRepository) // Kicks off data load on init

    // Verify that the exposed data is correct
    assertEquals(viewModel.firstUserName, UserAlice.name)
}

UserRepository की जगह कोई नकली प्रॉडक्ट इस्तेमाल करना, यूनिट टेस्ट में आसान होता है, क्योंकि ViewModel को टेस्टर ने बनाया है. हालांकि, इसे बदलना चुनौती भरा हो सकता है बड़े परीक्षणों में आर्बिट्ररी एलिमेंट का उपयोग करते हैं.

कॉम्पोनेंट और डिपेंडेंसी इंजेक्शन को बदलना

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

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

मैन्युअल तौर पर इस सुविधा को पाने के लिए, अपने ऐप्लिकेशन को डिज़ाइन किया जा सकता है. हालांकि, हमारा सुझाव है कि कॉम्पोनेंट को बदलने के लिए, Hilt जैसे डिपेंडेंसी इंजेक्शन फ़्रेमवर्क का इस्तेमाल करना जांच के समय आपके ऐप्लिकेशन में. हिल्ट टेस्टिंग गाइड देखें.

रोबोलेक्टिक

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

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