चम्मच और एम्मा का उपयोग करके Android अनुप्रयोगों के परीक्षण पर रिपोर्ट बनाना

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



एंड्रॉइड के लिए, बाकी सभी की तरह, Google ने खराब परीक्षण उपकरण प्रदान नहीं किए, लेकिन उनके साथ सब कुछ नहीं किया जा सकता है। परीक्षण के लिए, एक जनीट फ्रेमवर्क का उपयोग किया जाता है, जिसमें इसके पेशेवरों और विपक्ष हैं।



jUnit - यूनिट परीक्षण के लिए उपयोग किया जाता है, जो आपको प्रोग्राम स्रोत कोड के व्यक्तिगत मॉड्यूल की शुद्धता की जांच करने की अनुमति देता है। इस दृष्टिकोण का लाभ दूसरों से एकल मॉड्यूल का अलगाव है। इसी समय, इस पद्धति का उद्देश्य प्रोग्रामर को यह सुनिश्चित करने की अनुमति देता है कि मॉड्यूल, अपने आप से, सही ढंग से काम करने में सक्षम है। jUnit एक क्लास लाइब्रेरी है। लेकिन जिसने इस ढांचे का उपयोग करके परीक्षण लिखा था, उसने यह सुनिश्चित किया कि जीयूआई का परीक्षण करते समय यह पूरी तरह से असुविधाजनक था। अच्छे स्वाद का संकेत परीक्षणों द्वारा कवर किया गया कोड और एक रिपोर्ट है जो परीक्षणों द्वारा कोड कवरेज का प्रतिशत दिखाता है। हाल ही में, परियोजनाओं में, मुझे लोड से लेकर GUI तक, अन्य चीजों के साथ परीक्षण लिखना है, और मैं उन विशेषताओं के बारे में बात करना चाहूंगा जो मुझे मिलते हैं और इन रिपोर्टों को कैसे बनाया जाए। लेकिन पहले, मुख्य रूपरेखा के बारे में:



मुख्य रूपरेखा के उपयोग की अनुमानित तस्वीर। वास्तव में, प्रत्येक विकल्प खुद के लिए बनाता है। स्रोत कोड में जाने के लिए अनिच्छा के कारण कोई व्यक्ति रोबोटियम चुनता है, तो कोई एस्प्रेसो, इसके सहज इंटरफ़ेस के कारण।

चम्मच

चम्मच एक ढांचा है जो परीक्षणों के निष्पादन के दौरान डिवाइस या एमुलेटर की स्क्रीन से स्क्रीनशॉट ले सकता है और परिणामस्वरूप उनके बारे में रिपोर्ट बनाता है। स्क्रीनशॉट के अलावा, वह परीक्षण धावक के लॉग को रिपोर्ट में संलग्न करता है, और यदि परीक्षण विफल हो जाता है, तो यह एक पूर्ण स्टैक ट्रेस प्रदर्शित करता है, जो बहुत सुविधाजनक है। रिपोर्ट प्राप्त करने के लिए, निम्नलिखित कार्य करें:

• स्पून-क्लेयन टी और स्पून-रनर डाउनलोड करें ;
• परीक्षण के साथ प्रोजेक्ट के lib फ़ोल्डर में चम्मच-ग्राहक की प्रतिलिपि बनाएँ;
• उसी परियोजना में, एक फ़ोल्डर बनाएं (उदाहरण के लिए, चम्मच);
• कॉपी-रनर को बनाए गए फ़ोल्डर में;
• निम्नलिखित स्क्रिप्ट के साथ एक बैट-फाइल बनाएं:
  
  

call java -jar spoon-runner-1.1.1-jar-with-dependencies.jar -- apk Path\to\your\project \bin\project.apk -- test-apk Path\to\your\test-project \bin\tests.apk
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

उप-मापदंडों में आप परीक्षणों के लिए एक फिल्टर निर्दिष्ट कर सकते हैं, उदाहरण के लिए, आप स्क्रिप्ट में आकार माध्यम जोड़कर केवल "मध्यम" एनोटेशन के साथ परीक्षण चला सकते हैं।

अब स्क्रिप्ट इस तरह दिखाई देगी:

 call java -jar spoon-runner-1.1.1-jar-with-dependencies.jar -- apk Path\to\your\project \bin\project.apk -- test-apk Path\to\your\test-project \bin\tests.apk -- size medium
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

उपपरैटर्स की एक पूरी सूची जीथब पर इसके आधिकारिक पेज पर देखी जा सकती है। सब कुछ, अब जब परीक्षण लिख रहे हैं, तो बस वहां डालें जहां आपको आवश्यकता हो:

 Spoon.screenshot(activity, "state_changed"),
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

दूसरा तर्क वह रेखा है जहां स्क्रीनशॉट के ऊपर प्रकाश डाला जाएगा। हां, एक और विशेषता - इसके अंदर, यह रेगेक्स का उपयोग करता है, और जब हस्ताक्षर में रिक्त स्थान का उपयोग करते हैं तो एक अपवाद फेंकता है। हम एमुलेटर शुरू करते हैं या फोन कनेक्ट करते हैं, हमारी बैच फ़ाइल खोलें और यदि सब कुछ सही ढंग से किया गया है, तो आपको उसी फ़ोल्डर में एक रिपोर्ट दिखाई देगी:



डेवलपर की एक रिपोर्ट का आधिकारिक उदाहरण यहां है ।

मेरी परियोजना की रिपोर्ट यहाँ देखी जा सकती है ।

बुरा नहीं है, है ना? "चम्मच" का एक अन्य लाभ यह है कि यह सभी जुड़े उपकरणों पर एक साथ परीक्षण चलाता है, अर्थात यह एक रिपोर्ट में सभी उपकरणों से परिणाम एकत्र करेगा। एकमात्र और शायद महत्वपूर्ण माइनस यह है कि यह संवादों के स्क्रीनशॉट नहीं लेता है और यह देखना संभव नहीं है कि परीक्षण के दौरान इस पर क्या था। और वह अभी भी परीक्षणों के साथ कोड कवरेज पर एक रिपोर्ट नहीं बनाएगा! ठीक है, चलो इसे ठीक करते हैं।

एम्मा

सहमत, रिपोर्ट कम से कम योग्य लगती है



परीक्षण-कवर कोड का एक उदाहरण:



और क्रमशः आंशिक रूप से कवर किया गया:



सभी प्रारूपों में पूरी रिपोर्ट।



EMMA जावा में परीक्षण कवरेज को मापने और रिपोर्ट करने के लिए एक खुला स्रोत टूलकिट है। यह उपकरण एंड्रॉइड एसडीके में बनाया गया है और डेवलपर्स "बॉक्स से बाहर" रिपोर्ट उत्पन्न करने की क्षमता प्रदान करते हैं। मुख्य विशेषताएं:

• ऑफ़लाइन मोड में (लोड करने से पहले) और मक्खी पर कक्षा निरीक्षण के लिए समर्थन;
• समर्थित कवरेज प्रकार: पैकेज, वर्ग, विधि, रेखा और मुख्य इकाई। यह पता लगाना भी संभव है कि जब स्रोत कोड की एक पंक्ति केवल आंशिक रूप से कवर की जाती है;
• आउटपुट रिपोर्ट के प्रकार: पाठ, HTML, एक्सएमएल;

चींटी का उपयोग कर एक परियोजना का निर्माण

अपाचे चींटी विकास संरचनाओं को एप्लिकेशन परिनियोजन डिज़ाइन में बदलने के लिए एक उपकरण है। यह घोषणात्मक है और एप्लिकेशन को तैनात करने के लिए उपयोग किए जाने वाले सभी कमांड लाइन निर्देश सरल XML तत्वों द्वारा दर्शाए जाते हैं। अधिक विवरण यहां पाया जा सकता है ।

प्रोजेक्ट असेंबली प्रक्रिया का वर्णन करने के लिए, आपको चाहिए: एक कार्यशील परियोजना - MyProject और इसके लिए परीक्षण वाली परियोजना - MyProjectTests। आप उन नियमों के बारे में पढ़ सकते हैं जिनका यहां परीक्षण बनाते समय पालन किया जाना चाहिए।

सबसे पहले, चींटी का उपयोग करके एक परियोजना का निर्माण करते समय, आपको उन परियोजनाओं को इकट्ठा करने की आवश्यकता होती है जो आवेदन में पुस्तकालयों के रूप में उपयोग की जाती हैं। यदि कोई नहीं हैं, तो आप इस चरण को छोड़ सकते हैं। उदाहरण के लिए, एक परियोजना "google_play_service_lib" जैसे पुस्तकालयों का उपयोग करती है, आपको निम्न कार्य करने की आवश्यकता है:

- कमांड लाइन पर, स्थापित फ़ोल्डर पर जाएं sdk \ Tools (उदाहरण के लिए, D: \ android \ adt-bundle \ sdk \ Tools) और निष्पादित करें:

 android update lib-project -p MyLibProject
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

, जहाँ MyLibProject परियोजना में प्रयुक्त पुस्तकालय का मार्ग है। परिणामस्वरूप, build.xml प्रोजेक्ट रूट में दिखाई देना चाहिए और कंसोल में एक संदेश दिखाई देगा:

 Updated local.properties Updated file D:\Workspace\MyProject\build.xml Updated file D:\Workspace\MyProjectTests\proguard-project.txt
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

सभी पुस्तकालयों को असेंबल करने के बाद आपको वर्किंग प्रोजेक्ट को ही असेंबल करना होगा। ऐसा करने के लिए, आपको उसी फ़ोल्डर में करना होगा:

 android update project -p MyProject
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

जहाँ MyProject प्रोजेक्ट वर्क ब्रांच का रास्ता है। स्वाभाविक रूप से, AndroidManifest.xml इस फ़ोल्डर में होना चाहिए। स्क्रिप्ट build.xml को फिर से बनाएगी और वर्किंग प्रोजेक्ट बनाएगी। आप सबपामेटर्स के माध्यम से प्रोजेक्ट का नाम दर्ज कर सकते हैं, ताकि बाद में इसका उपयोग करना सुविधाजनक हो:

 android update project -p MyProject -n NameForProject
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

परीक्षण के साथ प्रोजेक्ट कैसे बनता है? सब कुछ समान और सुविधाजनक है। परीक्षण के साथ एक परियोजना के निर्माण के लिए स्क्रिप्ट:

 android update test-project -m ..\MyProject -p \MyProjectTests
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

, जहां MyProject वर्किंग प्रोजेक्ट का पथ है, और MyProjectTests परीक्षण के साथ प्रोजेक्ट का पथ है।

सब कुछ तैयार है! वैसे, इस कदम पर, पुस्तकालयों के उपयोग के कारण डेवलपर्स को समस्या हो सकती है! उदाहरण के लिए, एक परियोजना में, विभिन्न जार पुस्तकालयों को उन पुस्तकालयों के आधार पर संकलित किया जा सकता है जो आपके अन्य पुस्तकालयों में उपयोग किए जाते हैं। चींटी को समझ में नहीं आता है कि उनके साथ क्या किया जाए और परिणामस्वरूप असेंबली के दौरान कोई त्रुटि होती है। यही है, अगर किसी परियोजना के अंदर एक और एक ही पुस्तकालय का उपयोग किया जाता है, तो यह पहले से ही एक त्रुटि हो सकती है।

स्क्रिप्ट में परीक्षणों द्वारा कोड कवरेज की मात्रा की गणना शुरू करने के लिए, आपको उप-पैरामीटर में एम्मा को पंजीकृत करना होगा। शुरू करने से पहले, आपको एमुलेटर चलाने या डिवाइस को कनेक्ट करने की आवश्यकता है। निम्नलिखित स्क्रिप्ट परीक्षण के साथ परियोजना की शीर्ष शाखा पर कमांड लाइन पर निष्पादित की जाती है:

 ant clean emma debug install test
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

परीक्षणों के दौरान, एम्मा मुख्य परियोजना (मेटाडेटा) के बिन फ़ोल्डर में कवरेज.म फ़ाइल उत्पन्न करता है, सभी परीक्षणों को पारित करने के बाद आवश्यक अनुमतियाँ सेट करता है, स्थापित परियोजना के फ़ोल्डर में कवरेज ।ec फ़ाइल बनाता है, इन दो फ़ाइलों को परीक्षण परियोजना के बिन फ़ोल्डर में कॉपी करता है और उनके आधार पर एक ही फ़ोल्डर में एक रिपोर्ट उत्पन्न होती है।

नमूना रिपोर्ट के साथ मेरे प्रोजेक्ट के स्रोत जीथब पर पाए जा सकते हैं।

संक्षेप में कहना

आइए परीक्षणों को देखें, भले ही वे बहुत अच्छी तरह से लिखे गए हों। आप उन्हें जवाब देने के लिए देख सकते हैं कि वे आपके कोड को कितना कवर करते हैं? क्या आपके लिए एक हरे रंग की पट्टी होना पर्याप्त है जो एक दृश्य रिपोर्ट के रूप में आपके परीक्षणों के परिणाम को समग्र रूप से दिखाता है? मुझे नहीं लगता। काम के परिणामस्वरूप रिपोर्ट का उपयोग करना किसी विशेषज्ञ की क्षमता का स्तर दिखाता है, और जब परीक्षण स्वचालन की बात आती है, तो और भी अधिक। स्क्रिप्ट लिखना निश्चित रूप से आपको कुछ समय लग सकता है, लेकिन मेरा विश्वास करो, यह इसके लायक है!