अपने प्रश्न में पहलुओं के बहुत सारे हैं, लेकिन मेरी राय के लिए - आप शायद अपनी परियोजना में यूनिट-परीक्षण की जरूरत नहीं है।
यूनिट परीक्षण वास्तव में चमकते हैं जब आपको अपनी परियोजना में बहुत से व्यवसाय तर्क की आवश्यकता होती है। इस मामले में आप शायद अपने आवेदन को कई परतों (कहें, 3-स्तरीय आर्किटेक्चर) में विभाजित करना चाहते हैं, दूसरे के बीच, व्यापार-तर्क परत के लिए कुछ प्राकृतिक अलगाव जोड़ें और इसे यूनिट परीक्षणों के सुरक्षा नेट के साथ कवर करें।
यह सुरक्षा नेट व्यापार परत के के दौरान अपने गधे को कवर करता है, और यूनिट परीक्षणों से आप मुख्य चीजों में से एक है (टीडीडी हालांकि कुछ अच्छे अतिरिक्त साइड इफेक्ट्स प्रदान कर सकता है)।
हालांकि, यह सभी यूनिकॉर्न और बारिश और यूनिट-टेस्ट की लागत नहीं हो सकती है, और कभी-कभी उन्हें बहुत खर्च होता है। अच्छी इकाई परीक्षण अलग हैं (यानी कोड के छोटे हिस्से के साथ सौदा)। इसका मतलब है कि आपको अपनी कक्षाओं को परीक्षण के तहत रखने के लिए अमूर्तता की परतें जोड़नी होंगी।
इससे आपके सिस्टम या नकारात्मक पर सकारात्मक प्रभाव हो सकता है। लेयरिंग बढ़ती जटिलता की लागत के साथ आपके सिस्टम को अधिक लचीला बनाता है।
यह कहकर - यूनिट-परीक्षण का मूल्य आपके प्रोजेक्ट में पेश किए जाने वाले अमूर्त व्यवसाय-तर्क की मात्रा के समान है। आप इसके बारे में भी सोच सकते हैं - यदि यह आपके आर्किटेक्चर में अमूर्त परत जोड़ने के लिए अधिक है - यूनिट-टेस्ट न जोड़ें - वे केवल चीजों को और अधिक जटिल बनायेंगे (आर्किटेक्चर और बिल्ड वार)।
आपके विवरण के आधार पर - आपका सामान्य ऐप कुछ बाहरी सर्वर-साइड के लिए बहुत अधिक प्रस्तुति परत होता है। यह एंड्रॉइड हैंडसेट पर जानकारी प्रस्तुत करने के अलावा इतना नहीं है और उपयोगकर्ता क्रियाओं को सर्वर-साइड में कमांड में बदल देता है जहां मुख्य व्यवसाय तर्क (नियंत्रण) किया जाता है।
इस दृष्टिकोण कोड आप शायद लिखने के सबसे के साथ
"यह कैसे प्रदर्शित करने और है कि करने के लिए" या "इस में सर्वर और उस मामले संकेत करने के लिए कैसे" से संबंधित है। इस तरह का कोड स्पष्ट रूप से प्लेटफ़ॉर्म पर निर्भर करता है और इसका मतलब यह है कि यदि आप इसे परीक्षण के तहत रखना चाहते हैं तो आपको बहुत सारे एंड्रॉइड विशिष्ट कोड \ व्यवहार का नकल करना होगा।
अब, एंड्रॉइड कुछ हद तक विशिष्ट मंच है। यह दोनों प्रदर्शन अनुकूलित करने के लिए डिज़ाइन किया गया था और डेवलपर्स को ऐप्स को जल्दी से शुरू करने और उत्पादित करने की अनुमति देता था। अक्सर इसका मतलब है कि आपके द्वारा उपयोग किए जाने वाले "स्विस-चाकू" वर्गों की कुछ मात्रा \ विस्तारित होती है और आम तौर पर यह लेखन कोड को गति देती है, लेकिन उन वर्गों का मज़ाक उड़ाकर असली नरक बन सकता है। इस बात का जिक्र नहीं है कि आपको समझना होगा कि कैसे मजाक बनाने के लिए प्लेटफॉर्म काम करता है। दूसरे शब्दों में उन परीक्षणों को बनाने से ओवरहेड उच्च होने जा रहा है।
एक और बात यह है कि परीक्षण प्रस्तुति परतों के साथ गलत है कि वे व्यापार परतों की तुलना में अधिक गतिशील रूप से परिवर्तित करने के लिए जाते है। और, निश्चित रूप से इसका मतलब है कि आपको उन परीक्षणों को दोबारा करना होगा जो अधिक ओवरहेड जोड़ते हैं।
हालांकि मुझे विभिन्न उपयोगिता/सहायक कक्षाओं के बारे में एक बात कहना है। यहां तक कि अगर इन कक्षाओं प्रस्तुति परत से संबंधित हैं और एंड्रॉयड कोड निर्भर करते हैं, लेकिन कुछ नहीं बल्कि गैर तुच्छ तर्क और यह नकली है और उनके लिए इकाई परीक्षण लिखने के लिए आसान है करते हैं, यह वास्तव में यह करने के लिए एक अच्छा विचार हो सकता है। हालांकि, अगर आपके पास बहुत सारे कोड हैं - यह एक संकेत हो सकता है कि आपने अपने आर्किटेक्चर/लेयरिंग को अच्छी तरह से डिज़ाइन नहीं किया है, और आप जो भी कर रहे हैं उसे पुनर्विचार करने की आवश्यकता है।
अंत में अपने प्रश्न का उत्तर के लिए आपको पहले इन सवालों का जवाब करने के लिए है:
यह अमूर्त परत है कि आपके आवेदन के लिए मंच से अलग है जोड़ने के लिए overdesign किया जाएगा (अपने मामले कहीं भी होगी में की तरह लगता है) ? यदि हां - यूनिट-टेस्ट का उपयोग न करें - वे केवल आपको धीमा कर देंगे। यदि नहीं - तो उनका उपयोग करें।
आप एक बहुत refactor करने के लिए जा रहे हैं? यदि यह बहुत सारे कोड और इस प्रकार रखरखाव के साथ बड़ी परियोजना है - तो आप शायद लेयरिंग और यूनिट-टेस्ट में निवेश करेंगे (लेकिन, एक नज़र में, ऐसा नहीं लगता है कि यह आपका मामला है)। यदि यह आपका मामला नहीं है - यूनिट-टेस्ट से परेशान न हों और तेजी से जाएं।
आप मंच एक बहुत अपने इकाई परीक्षण लिखने के लिए नकली की जरूरत है? यदि हां (आपका मामला प्रतीत होता है) - यूनिट परीक्षण न लिखें - वे प्रयास के लायक नहीं हैं।
आशा है कि इससे मदद मिलेगी।