आपको किस चीज़ की जांच करनी चाहिए, यह कई बातों पर निर्भर करता है. जैसे, ऐप्लिकेशन का टाइप, डेवलपमेंट टीम, लेगसी कोड की संख्या, और इस्तेमाल किए गए आर्किटेक्चर. यहां दिए गए सेक्शन में बताया गया है कि ऐप्लिकेशन में किस चीज़ की जांच करनी है, यह तय करते समय शुरुआती डेवलपर को किन बातों का ध्यान रखना चाहिए.
टेस्ट डायरेक्ट्री का संगठन
Android Studio में किसी सामान्य प्रोजेक्ट में दो डायरेक्ट्री होती हैं. इनमें, टेस्ट को उनके रन होने के माहौल के हिसाब से रखा जाता है. अपने टेस्ट को यहां दी गई डायरेक्ट्री में व्यवस्थित करें:
androidTestडायरेक्ट्री में ऐसे टेस्ट होने चाहिए जो असल या वर्चुअल डिवाइसों पर चलते हों. इस तरह के टेस्ट में इंटिग्रेशन टेस्ट, एंड-टू-एंड टेस्ट, और ऐसे अन्य टेस्ट शामिल होते हैं जिनमें जेवीएम अकेले आपके ऐप्लिकेशन के फ़ंक्शन की पुष्टि नहीं कर सकता.testडायरेक्ट्री में, आपकी लोकल मशीन पर चलने वाले टेस्ट होने चाहिए. जैसे, यूनिट टेस्ट. ऊपर बताए गए टेस्ट के उलट, ये ऐसे टेस्ट हो सकते हैं जो किसी स्थानीय जेवीएम पर चलते हैं.
ज़रूरी यूनिट टेस्ट
सबसे सही तरीके का पालन करते समय, आपको इन मामलों में यूनिट टेस्ट का इस्तेमाल करना चाहिए:
- ViewModels या प्रज़ेंटर के लिए यूनिट टेस्ट.
- डेटा लेयर के लिए यूनिट टेस्ट, खास तौर पर रिपॉज़िटरी. ज़्यादातर डेटा लेयर, प्लैटफ़ॉर्म पर निर्भर नहीं होनी चाहिए. ऐसा करने से, टेस्ट डबल्स, टेस्ट में डेटाबेस मॉड्यूल और रिमोट डेटा सोर्स को बदल सकते हैं. Android में टेस्ट डबल का इस्तेमाल करने के बारे में गाइड देखें
- प्लैटफ़ॉर्म पर काम करने वाली अन्य लेयर के लिए यूनिट टेस्ट, जैसे कि डोमेन लेयर. इनमें यूज़ केस और इंटरैक्टर भी शामिल हैं.
- स्ट्रिंग में बदलाव करने और गणित जैसी यूटिलिटी क्लास के लिए यूनिट टेस्ट.
कभी-कभी होने वाले मामलों की जांच करना
यूनिट टेस्ट में, सामान्य और असामान्य दोनों तरह के केस पर ध्यान दिया जाना चाहिए. एज केस ऐसे असामान्य परिदृश्य होते हैं जिन्हें टेस्टर और बड़े टेस्ट में पकड़ना मुश्किल होता है. उदाहरण के लिए:
- नेगेटिव संख्याओं, शून्य, और सीमा वाली स्थितियों का इस्तेमाल करके किए जाने वाले गणित के ऑपरेशन.
- नेटवर्क कनेक्शन से जुड़ी सभी संभावित गड़बड़ियां.
- गलत फ़ॉर्मैट वाला डेटा, जैसे कि गलत फ़ॉर्मैट वाला JSON.
- फ़ाइल में सेव करते समय, स्टोरेज भर जाने का अनुकरण करना.
- किसी प्रोसेस के बीच में ऑब्जेक्ट फिर से बनाया गया हो. जैसे, डिवाइस को घुमाने पर होने वाली गतिविधि.
ऐसी यूनिट टेस्ट जिनसे बचना चाहिए
कुछ यूनिट टेस्ट की वैल्यू कम होने की वजह से, उनसे बचना चाहिए:
- ये टेस्ट, आपके कोड के बजाय फ़्रेमवर्क या लाइब्रेरी के सही तरीके से काम करने की पुष्टि करते हैं.
- ऐक्टिविटी, फ़्रैगमेंट या सेवाओं जैसे फ़्रेमवर्क एंट्री पॉइंट में, कारोबारी लॉजिक नहीं होना चाहिए. इसलिए, यूनिट टेस्टिंग को प्राथमिकता नहीं दी जानी चाहिए. गतिविधियों के लिए यूनिट टेस्ट की बहुत कम वैल्यू होती है, क्योंकि ये ज़्यादातर फ़्रेमवर्क कोड को कवर करते हैं और इनके लिए ज़्यादा सेटअप की ज़रूरत होती है. यूज़र इंटरफ़ेस (यूआई) टेस्ट जैसे इंस्ट्रूमेंट किए गए टेस्ट, इन क्लास को कवर कर सकते हैं.
यूज़र इंटरफ़ेस (यूआई) की जांच करना
आपको कई तरह के यूज़र इंटरफ़ेस (यूआई) टेस्ट करने चाहिए:
- स्क्रीन यूज़र इंटरफ़ेस (यूआई) टेस्ट, एक ही स्क्रीन पर उपयोगकर्ता के अहम इंटरैक्शन की जांच करते हैं. ये बटन पर क्लिक करने, फ़ॉर्म में टाइप करने, और दिखने वाली स्थितियों की जांच करने जैसी कार्रवाइयां करते हैं. शुरुआत के लिए, हर स्क्रीन के लिए एक टेस्ट क्लास बनाना अच्छा होता है.
- यूज़र फ़्लो टेस्ट या नेविगेशन टेस्ट, जो सबसे सामान्य पाथ को कवर करते हैं. ये जांच, नेविगेशन फ़्लो में आगे बढ़ने वाले उपयोगकर्ता की नकल करती हैं. ये आसान टेस्ट होते हैं. इनकी मदद से, शुरू करने के दौरान होने वाले क्रैश की जांच की जा सकती है.
अन्य टेस्ट
स्क्रीनशॉट टेस्ट, परफ़ॉर्मेंस टेस्ट, और मंकी टेस्ट जैसे और भी खास टेस्ट हैं. टेस्ट को मकसद के हिसाब से भी बांटा जा सकता है. जैसे, रिग्रेशन, सुलभता, और काम करने की क्षमता.
इसके बारे में और पढ़ें
अलग से टेस्ट करने के लिए, आपको अक्सर टेस्ट किए जा रहे विषय की डिपेंडेंसी को नकली या मॉक डिपेंडेंसी से बदलना पड़ता है. आम तौर पर, इन्हें "टेस्ट डबल" कहा जाता है. Android में टेस्ट डबल का इस्तेमाल करना लेख में, इनके बारे में ज़्यादा पढ़ें.
यूनिट और यूज़र इंटरफ़ेस (यूआई) टेस्ट बनाने का तरीका जानने के लिए, टेस्टिंग के लिए कोडलैब देखें.