Android के विकास के लिए डिजाइन पैटर्न। भाग 2 - एमवीपी और यूनिट परीक्षण। जेडी वे

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

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

मैं आपको जेडी के रास्ते पर रखने की कोशिश करूँगा और आपको यूनिट के परीक्षण और बंद आँखों से अन्य तकनीकों की मदद से कीड़े के ढेर को कुचलने के लिए सिखाना होगा।

आदर्श दृश्य प्रस्तुतकर्ता (MVP) क्या है

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

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

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

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

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

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

और अब परीक्षण में:
1. हम एक वर्ग को प्रतिनिधित्व के लिए एक स्टब बनाते हैं और हम बताते हैं कि यह किस क्षेत्र के मूल्यों को लौटाएगा।
2. डेटाबेस के लिए एक स्टब क्लास बनाएं जो सेवटॉबीडी विधि को कॉल करते समय बस उस पर दिए गए मानों को सहेजता है
3. एक प्रस्तोता बनाएं और इसके लिए बनाए गए स्टब्स को पास करें।
4. हम प्रस्तुतकर्ता विधि को "सेव" कहते हैं
5. जाँच करें कि आवश्यक मान डीबी स्टब में दिखाई दिए, अन्यथा प्रस्तुतकर्ता में एक त्रुटि है।

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

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

"शांत हो जाओ, हे युवा पडवन"

हां, किसी भी पैटर्न को कोड की अतिरिक्त लाइनें लिखने की आवश्यकता होती है, आपको बस यह समझने की आवश्यकता है कि इससे कैसे लाभ होगा।

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

तो, इस तरह से यूनिट परीक्षणों का उपयोग नहीं किया जा सकता है। उनका उपयोग किया जाना चाहिए ताकि वे डेवलपर के लिए समय बचा सकें।

आगे, मैं आपको परीक्षण का उपयोग करके विकास प्रक्रिया को व्यवस्थित करने का तरीका बताऊंगा, ताकि यह डेवलपर को विशेष रूप से लाभान्वित करे।

एक उदाहरण के रूप में, चलो वही रूप लेते हैं जहां आपको डेटा दर्ज करने की आवश्यकता होती है, "सहेजें" बटन पर क्लिक करें, डेटा की जांच करें, यदि त्रुटियां हैं, तो उन्हें उपयोगकर्ता को दिखाएं, यदि नहीं, तो उन्हें डेटाबेस में भेजें।

एक प्रस्तुतकर्ता के लिए एक दृश्य और पूर्व निर्धारित बनाना

सबसे पहले, आपको एंड्रॉइड के मामले में एक फॉर्म (दृश्य) बनाने की आवश्यकता है, यह गतिविधि वर्ग का उत्तराधिकारी है। मूल्यों को दर्ज करने, त्रुटि संदेश और हैंडलर के साथ "सहेजें" बटन को प्रदर्शित करने के लिए उस पर नियंत्रण रखना आवश्यक है।

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

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

व्यू कंस्ट्रक्टर में, प्रस्तुतकर्ता का एक उदाहरण बनाएं और उसे इस दृश्य का लिंक दें। विधि में दृश्य में, "सहेजें" बटन के हैंडलर बस प्रस्तुतकर्ता में संबंधित विधि पर कॉल लगाते हैं।

यहाँ एक उदाहरण है

public class View extends Activity implements IView { Presenter presenter; public View(Bundle savedInstanceState) { presenter = new Presenter(this); } public void setName(String name) { tvName.setText(name); } public void getName() { return tvName.getText(); } public void onSave(View v) { presenter.onSave(); } } 

यहाँ प्रस्तुतकर्ता का एक उदाहरण है

 public class presenter { IView view; public presenter(IView view) { this.view = view; view.setName("example name"); } public onSave() { string name = view.getName(); } } 

पहले चरण के लिए कोड तैयार है।
आपको डिबगर में प्रोग्राम चलाने और यह सुनिश्चित करने की आवश्यकता है कि जब आप फॉर्म खोलते हैं तो सही नाम प्रदर्शित होता है, और यदि आप एक नया नाम दर्ज करते हैं और "सहेजें" पर क्लिक करते हैं, तो प्रस्तुतकर्ता को सही मूल्य मिलेगा।

पहले चरण में, कोई इकाई परीक्षण नहीं हैं और कोई विशेष समय की बचत नहीं है, लेकिन लागत बड़ी नहीं है।

"अपनी आँखें बंद करो, हे युवा पडवन।"

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

रहस्य छोटे टुकड़ों में प्रस्तुतकर्ता को जोड़ने और इस टुकड़े का परीक्षण करने के लिए, आटा का एक टुकड़ा जोड़ना है।

प्रस्तुतकर्ता कार्यक्षमता भरें। निर्माण के बाद, उसे डेटाबेस से नाम पढ़ना होगा और इसे दृश्य में पास करना होगा। और सहेजते समय, प्रस्तुति से नाम प्राप्त करें और इसे डेटाबेस में सहेजें।

 public class presenter { IView view; IDataBase dataBase; int Id; public presenter(IView view, IDataBase dataBase) { this.view = view; this.dataBase = dataDase; id = view.getId(); string name = dataBase.loadFromDB(id); view.setName(name); } public onSave() { string name = view.getName(); dataBase.saveToDB(id, name); } } 

यह स्पष्ट है कि एक ही समय में हमें आईडी प्राप्त करने के लिए इंटरफ़ेस और देखने के लिए एक नई विधि को जोड़ने की आवश्यकता है, लेकिन अब के लिए हमने "अपनी आँखें खोलें", अर्थात, प्रस्तुति को जांचने के लिए एप्लिकेशन लॉन्च किया है। हम इसे बाद में करेंगे, और यदि कोई त्रुटि है, तो हम इसे एक सेकंड में ठीक कर देंगे।

इसलिए हमने प्रस्तुति का एक टुकड़ा लिखा और अब परीक्षण का एक टुकड़ा लिखें।

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

टेस्ट विधि उदाहरण

 public void testOpenAndSave() { IView view = createMock(IView.class); //    IDataBase dataBase = CreateMock(IDataBase.class);//    expect(view.getId()).andReturn(1); // presenter       id 1 expect(dataBase.LoadFromDB(1)).andReturn("source name"); // presenter   ,  "source name" expect(view.setName("source name")); //       expect(view.getName()).andReturn("destination name"); // presenter   ,   ,  "destination name". expect(dataBase.SaveToDB(1, "destination name")); //,       . Presenter presenter = new Presenter(view, dataBase); //  presenter       presenter.Save();//   ""; //,          verify(view); verify(dataBase); } 

बस यह मत समझो कि परीक्षण में कोड प्रस्तुतकर्ता में उतना ही है। यह इसके लायक है।

हम परीक्षण चलाते हैं और देखते हैं कि सब कुछ ठीक है, या ऐसा करें कि सब कुछ अच्छा हो जाए।

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

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

और यहाँ लाभ है

और अब मैं दिखाऊंगा कि विकास के समय को कम करने और गुणवत्ता में सुधार के रूप में लाभ कहां है।

प्रस्तुतकर्ता के आगे के विकास में लाभ दिखाई देता है।

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

ऐसा करने के लिए, नाम सही है या नहीं यह जाँचने के लिए प्रस्तुतकर्ता में आवश्यक कोड जोड़ें और यदि यह गलत है, तो setErrorText () विधि को कॉल करें, और डेटाबेस में सेव को कॉल न करें।

अगला, बस परीक्षण की प्रतिलिपि बनाएँ और प्रस्तुति के लिए सिमुलेशन संपादित करें। अब गेटनेम () को कॉल करते समय गलत नाम वापस करना चाहिए और सही तर्क के साथ setErrorText () विधि को कॉल करने की प्रतीक्षा करें, इस प्रकार जाँचें कि त्रुटि संदेश सही है। और डेटाबेस के लिए सिमुलेशन को जांचना चाहिए कि SaveToDB विधि को कभी भी कॉल नहीं किया गया है, या 0 बार कॉल किया गया है।

हम उन सभी परीक्षणों को चलाते हैं जिन्हें हम देखते हैं, नया परीक्षण ठीक काम करता है। लेकिन अतीत बीतता नहीं है। हम एक बेवकूफ गलती के लिए खुद को माथे पर मारते हैं और इसे जल्दी से ठीक करते हैं।
और अब दोनों परीक्षण काम करते हैं।

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

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

लेकिन हमारे पास परीक्षण हैं। इसलिए, हम आसानी से विभिन्न परीक्षण मामलों को अनुकरण कर सकते हैं और बैचों में कीड़े को ठीक कर सकते हैं, क्योंकि पिछले सभी परीक्षण मामलों को भी जांचा जाएगा।

परिणामस्वरूप, हमें एक उच्च-गुणवत्ता वाला कोड मिला, और इस तथ्य के कारण समय की बचत हुई कि हमें उन त्रुटियों से विचलित नहीं होना है जो परीक्षकों को मिलीं, और फिर सबसे लंबे समय तक यह जांचने के लिए कि अन्य सभी परीक्षण मामले त्रुटि को ठीक करने से नहीं टूटे।

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

जेडी बनना आसान नहीं है।

हां। एक सच्चे जेडी को परीक्षण लिखने के कई और ट्रिक्स पता होने चाहिए, ताकि आवश्यकताएं बदलते समय परीक्षण समर्थन, प्रारंभिक विकास से मिलने वाले सभी लाभों के बारे में ध्यान न दें।

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

मेरा मानना ​​है कि इंटरनेट पर आप कई ऐसी ट्रिक्स पा सकते हैं जिससे आप असली जेडी मास्टर बन सकेंगे।

मुख्य बात यह है कि आप पहले से ही जेडी के मार्ग पर चल चुके हैं और जानते हैं कि इसका पालन कैसे करना है :)

अन्य लेखों में पढ़ें

- परिचय
- एमवीपी और यूनिट परीक्षण। जेडी वे
- यूजर इंटरफेस, परीक्षण, AndroidMock
- डेटा की बचत। डोमेन मॉडल, रिपॉजिटरी, सिंगलटन और बीडीडी
- सर्वर साइड, रोबूगाइस, परीक्षण का कार्यान्वयन
- छोटे कार्य, सेटिंग्स, लॉगिंग, ProGuard