2016-01-26 4 views
6

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

मुझे पता चला कि ज्यादातर बार मुझे एपीआई कॉल में बग मिलती है, लेकिन मैं अभी भी समझ नहीं पा रहा हूं कि उनके लिए यूनिट परीक्षण कैसे लिखें (& मूल कोड टेस्ट करने योग्य कैसे करें)।

मेरा पीछा समारोह के बारे में बताएं:

मैं एक समारोह कॉल setOffenceList चला रहा हूँ()। फ़ंक्शन के अंदर कई क्रियाएं हो रही हैं।

i) RestClient लोड करें और यूआरएल पास करें।

ii) JSON एपीआई के RestClient बात और) प्रतिक्रिया

ii मिल रहा onSuccess (स्ट्रिंग प्रतिक्रिया के अंदर प्रतिक्रिया हड़पने) समारोह

iii) एक सरणी

अंदर JSON डेटा और दुकान पार्स

iv) मैं (किसी और सूची दृश्य में डेटा को दिखाएगा एक त्रुटि संदेश दिखाई देते हैं) सफलता तो

इस कोड है:

public class OffenceFrag extends Fragment { 


    @Override 
    public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) { 
     View view = inflater.inflate(R.layout.frag_offence, container, false); 
     //run API call 
     setOffenceList(); 
     return view; 
    } 

    private void setOffenceList() { 
     String url = Paths.SITE_URL ; 
     RestClient.get(url, null, new AsyncHttpResponseHandler() { 

      @Override 
      public void onStart() { 
       Toast.makeText(getActivity(), "Loading offences...", Toast.LENGTH_SHORT).show(); 
      } 

      @Override 
      public void onSuccess(String response) { 

       //Parse JSON 
       JSONArray jsonArray; 
       try { 

        JSONObject jsonObj = new JSONObject(response); 
        if(jsonObj.getString("status").equalsIgnoreCase("Success")){ 

         jsonArray = new JSONArray(jsonObj.getString("data")); 
         if(jsonArray.length() > 0){ 
          for (int i = 0; i < jsonArray.length(); i++) { 

           JSONObject row = jsonArray.getJSONObject(i); 
           OffenceORM off = new OffenceORM(); 
           off.setOffenceId(row.getString("offence_id")); 
           off.setPhoto(row.getString("photo")); 
           off.setSubmittedBy(row.getString("submitted_by")); 
           offenceList.add(off); 
          } 
         } 

         //Success: Show the list view 
         setOffenceAdapter(); 
         Toast.makeText(getActivity(), "Successfully Loaded", Toast.LENGTH_LONG).show(); 

        } else { 
         //Failed: show error message 
         Toast.makeText(getActivity(), "There are no offences submitted under project", Toast.LENGTH_LONG).show(); 
        } 

       } catch (Exception e) { 
        Log.e("exception", e.getMessage()); 
       } 
      } 

      @Override 
      public void onFailure(Throwable error, String content) { 
       Log.e("failed", error.getMessage()); 
      } 

      @Override 
      public void onFinish() { 

      } 
     }); 
    } 


}//end 

मैं वास्तव में समझ नहीं पा रहा हूं कि मैं उपर्युक्त कोड की तरह कुछ परीक्षण फ़ंक्शन कैसे लिख सकता हूं।

क्या आप कृपया मुझे दिखा सकते हैं कि इस कोड को टेस्ट करने योग्य टुकड़ों में कैसे तोड़ना है और उन्हें यूनिट परीक्षण कार्यों को लिखना है?

बहुत बहुत धन्यवाद!

+1

एक दृष्टिकोण एकीकरण परीक्षण लिखना होगा जो आरईएसटी एपीआई का उपयोग करता है। Http://stackoverflow.com/questions/10752/what-is-the-difference-between-integration-and-unit-tests देखें। एक यूनिट टेस्ट दृष्टिकोण में आप आम तौर पर 'लेआउट इन्फ्लैटर inflater, ViewGroup कंटेनर, बंडल सेवृत्तस्टेंसस्टेट' का नकल करेंगे, उन्हें 'ऑफेंसफ्रैग' पर पास कर दें। onCreateView() 'और जोर देकर कहते हैं कि ऑफेंसफ्रैग आपको – Kirby

उत्तर

1

आप फ्रैगमेंट में बहुत अधिक चीजें कर रहे हैं, परीक्षण करना और बनाए रखना मुश्किल है।

मैं अपनी परियोजनाओं में एमवीपी पैटर्न का उपयोग कर रहा हूं, जो प्रस्तुति परत को तर्क से अलग करने की अनुमति देता है, सभी कोड को खंड/गतिविधि में रखने से परहेज करता है।

चेक इस अनुच्छेद: http://antonioleiva.com/mvp-android/

और GitHub में संबंधित कोड नमूना: https://github.com/antoniolg/androidmvp

4

केवल और केवल एक अच्छे डिजाइन मदद कर सकते हैं आसान परीक्षण इकाई बना रही है। यही कारण है कि टेस्ट संचालित विकास वहाँ है। ताकि आप गलत डिजाइन के साथ नहीं जा सकें।

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

जहां तक ​​अन्य एपी के पास एपी डेवलपर के मुद्दे की तुलना में कोई समस्या नहीं है। जब आप अन्य एपीआई कोड पर कॉल करते हैं तो आप अपने कोड की कार्यक्षमता का परीक्षण करने के लिए मॉकिटो जैसे नकली ढांचे का उपयोग कर सकते हैं। यदि आप अपना स्वयं का एपीआई विकसित कर रहे हैं तो टेस्ट एपीआई कोड अलग से।

डिजाइन सिद्धांत

  • एस की तरह अच्छे डिजाइन के लिए पालन किया जाना चाहिए - एकल ज़िम्मेदारी नहीं सिद्धांत
  • ओ - ओपन बंद कर दिया सिद्धांत
  • एल - Liskov प्रतिस्थापन सिद्धांत
  • मैं - इंटरफ़ेस अलगाव सिद्धांत
  • डी - निर्भरता उलटा सिद्धांत

महत्वपूर्ण बातें: इकाई परीक्षण मामले प्रति

  • एक ज़ोर विधि कॉल
  • सिर्फ परीक्षण के लिए कक्षाओं को संशोधित न करें।
  • इंटरफेस का उपयोग
  • एक विधि में बहुत अधिक कथन या कार्यक्षमता न डालें।
  • बहुत बड़ी कक्षाएं न बनाएं।
  • उपयोग TDD ....... और भी कई

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

सावधानीपूर्वक उस कार्यक्षमता को दूर करें जिसे आप अपनी कक्षाओं में परीक्षण करना चाहते हैं।

यह आपके एप्लिकेशन कोड को अधिक मजबूत, सरल और स्पष्ट बना देगा।

+3

' प्रति यूनिट टेस्ट केस 'पर एक जोर विधि कॉल करने की अपेक्षा करता है - यह हमेशा संभव नहीं होता है। उदाहरण के लिए: कोई भी परीक्षण में नल की जांच करता है और नतीजे का मूल्य दूसरे परीक्षण में होता है। – Bevor

1

टीडीडी का उपयोग करने के लिए रोहित खटकर की सलाह निश्चित रूप से आपके द्वारा विकसित अगले कोड के लिए विचार करने लायक है। लेकिन, अब यह कोड मौजूद है और आप पूछ रहे हैं कि "इस कोड को टेस्टेबल टुकड़ों में कैसे तोड़ना है": आप पहले टेस्टेबिलिटी को अनदेखा कर सकते हैं, और बस इस कोड को छोटे टुकड़ों में तोड़ने का प्रयास करें: क्लास परिभाषाओं को विभाजित करें और विधियों को विभाजित करें, सामान्य रूप से पठनीयता को अनुकूलित करने के लिए। आपको पहले से ही कुछ अनावश्यकता मिल जाएगी (यदि लूप के आसपास है)।

असल में, परिणामी तरीकों में से प्रत्येक के पास अन्य वर्गों पर कम निर्भरता होगी। फिर, आप इन निर्भरताओं को कम करने पर ध्यान केंद्रित कर सकते हैं। निर्भरता तोड़ने के दृष्टिकोण के पूरे समूह के लिए विरासत कोड से निपटने पर माइकल फेदर की पुस्तक देखें। संपादित करें: किसी ने निर्भरता ब्रेकिंग तकनीकों की सूची निकाली है (केवल उच्च स्तरीय विवरण, हालांकि): http://rubyexperiences.blogspot.de/2005/12/dependency-breaking-techniques-from.html

संबंधित मुद्दे