🐦 👩🏼‍🏭 🦎 विंडोज फोन में यूनिट टेस्टिंग के दौरान कोड कवरेज कंट्रोल 👨‍❤️‍💋‍👨 🚈 🤖

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

समस्या का बयान

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

सामान्य दृष्टिकोण

जैसा कि मैंने पहले ही लिखा था , विंडोज फोन रनटाइम में कोड कवरेज को नियंत्रित करने के लिए कोई साधन नहीं थे। नागग और हलकर की सलाह पर , मैंने पोर्टेबल क्लास लाइब्रेरी में एप्लिकेशन की कार्यक्षमता (तर्क) के साथ कोड प्रदान किया। इससे कवरेज नियंत्रण के साथ मानक .NET फ्रेमवर्क वातावरण में परीक्षण चलाना संभव हो गया। इसके अलावा, यह दृष्टिकोण निरंतर एकीकरण की प्रणाली के साथ shamanism को समाप्त करता है, और परीक्षणों के निष्पादन समय को भी कम करता है।

इस प्रकार, एक सरलीकृत तरीके से, आवेदन को तीन घटकों के रूप में दर्शाया जा सकता है:

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

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

वेब सर्वर के साथ काम करना (अनुरोध भेजना और प्रतिक्रिया प्राप्त करना)
फाइलों के साथ काम करना (बचत करना, पढ़ना, सूची प्राप्त करना)
स्ट्रिंग संसाधन स्थानीयकरण
इंटरनेट कनेक्शन उपलब्धता की जाँच करना
कुछ और

इस पर थोड़ा और विचार करें। आवेदन की सामान्यीकृत योजना इस प्रकार है:

एक HTTP अनुरोध सर्वर पर भेजा जाता है
उत्तर स्वीकार किया गया
उत्तर पार्स / संसाधित
Disassembly के परिणाम प्रदर्शित किए जाते हैं।

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

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

चलिए आगे बढ़ते हैं। प्रसंस्करण के दौरान, डेटा को कैश किया जा सकता है - डिवाइस पर फ़ाइलों के रूप में सहेजा जाता है। हालाँकि, PCL में पूर्ण फ़ाइल प्रबंधन उपकरण नहीं है। यह इस तथ्य के कारण है कि विभिन्न रनटाइम अलग-अलग भंडारण संगठन तंत्र का उपयोग करते हैं। तो, परिचित .NET में हम "साधारण" फाइलें (उदाहरण के लिए, File ) हैं, और विंडोज फोन में यह IsolatedStorageFile । हमें यह नहीं भूलना चाहिए कि परीक्षण के दौरान हमें इस तरह के भंडार का अनुकरण करने की भी आवश्यकता होगी।

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

नियंत्रण का उलटा

सन्निकटन की एक निश्चित डिग्री के साथ, इस खंडन को नियंत्रण का वैज्ञानिक उलटा कहा जाता है। मैं जंगल में नहीं ~~जाऊंगा~~ , क्योंकि मैं ~~खुद~~ नेटवर्क में इस विषय पर ~~पर्याप्त~~ सामग्री ~~नहीं जानता~~ हूं, मैं केवल मुख्य बिंदुओं का वर्णन करूंगा। मैं अर्थ के संभावित विकृतियों के लिए गुरु से अग्रिम में माफी मांगता हूं - मैं टिप्पणियों का इंतजार कर रहा हूं, अगर अचानक।

उदाहरण के लिए, आइए फाइल इंटरफेस देखें:

  public interface IFileStorage { Stream GetWriteFileStream(string fileName); Stream GetReadFileStream(string fileName); bool IsFileExists(string fileName); List<string> GetAllFileNames(string path); }

यह इंटरफ़ेस उनके भंडारण के विवरण में जाए बिना फाइलों पर काम करने के लिए पर्याप्त है। तदनुसार, यह इस इंटरफ़ेस और पीसीएल के बारे में है जो अधिक कुछ नहीं जानता है। यह विंडोज फोन एप्लिकेशन में कार्यान्वित किया जाता है, और कार्यान्वयन IsolatedStorageFile का उपयोग करता है।
यह इंटरफ़ेस एक परीक्षण DLL में भी लागू किया गया है, और यह बहुत ही आदिम है - सभी फ़ाइलों को मेमोरी में Dictionary<string, MemoryStream> के रूप में संग्रहीत किया जाता है। इस प्रकार, कार्यक्रम का तर्क खुश है, यह सोचकर कि यह वास्तविक फाइलों के साथ काम करता है, और हम संतुष्ट हैं, उसी समय से हम परीक्षण स्वतंत्रता की समस्या को हल कर रहे हैं। एक नया परीक्षण - कक्षा का एक नया उदाहरण - एक स्वच्छ "फाइल सिस्टम"।

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

  public interface IContainer { IFileStorage FileStorage { get; } IDataRequest DataRequest { get; } ILocalizer Localizer { get; } IUiExtenter Extender { get; } DateTime Now { get; } }

मैंने इसे "कंटेनर" कहा, हालांकि "नियंत्रण के व्युत्क्रम" खाका की शब्दावली में यह पूरी तरह से सही नहीं हो सकता है।
यह इंटरफ़ेस हमारे PCL लॉजिक टूल को फाइल ( FileStorage ), सर्वर अनुरोधों ( DataRequest ), स्थानीयकरण ( Localizer ) और अन्य चीजों ( Extender ) के साथ काम करने के लिए देता है, DataRequest संक्षिप्तता के लिए एक इंटरफ़ेस में संयोजित किया गया है।
अलग से, मैं अब संपत्ति पर ध्यान दें। यह विशेष रूप से परीक्षण के लिए है। तथ्य यह है कि कई स्थानों पर तर्क वर्तमान समय से जुड़ा हुआ है, और परीक्षण वातावरण के सही अनुकरण के लिए इस समय को बदलना होगा। सिस्टम का समय बदलना एक बुरा विचार है, यही वजह है कि यह संपत्ति दिखाई दी। मुख्य बात यह थी कि DateTime.Now बजाय आपको इस संपत्ति का उपयोग करने की आवश्यकता है।
कंटेनर में दो कार्यान्वयन हैं - विंडोज फोन एप्लिकेशन और टेस्ट डीएलएल में। प्रत्येक कंटेनर अपने इंटरफेस कार्यान्वयन "फिसल गया"। इसलिए, परीक्षण DLL में कंटेनर IDataRequest को स्टब के रूप में कार्यान्वित IDataRequest है जिससे परीक्षण सर्वर की प्रतिक्रियाओं और संचार समस्याओं का अनुकरण कर सकते हैं।
एक वस्तु जो IContainer को लागू करती है वह अनुप्रयोग की शुरुआत में बनाई जाती है। परीक्षण के दौरान, प्रत्येक परीक्षण के लिए एक नई ऐसी वस्तु बनाई जाती है। अनुप्रयोग तर्क को प्रबंधित करने वाली कक्षाओं में इस ऑब्जेक्ट का संदर्भ होना चाहिए। ऐसा करने का एक आसान तरीका सभी वर्गों के कंस्ट्रक्टरों में एक लिंक की आवश्यकता है।
बेशक, नियंत्रण योजनाओं को लागू करने के ~~लिए~~ कई तैयार ~~बाइक~~ हैं, उदाहरण के लिए, एकता एप्लीकेशन ब्लॉक , लेकिन मैंने इस विकल्प को चुना, मुख्य रूप से शैक्षिक उद्देश्यों के लिए। "वयस्क" परियोजनाओं में, निश्चित रूप से, तैयार किए गए समाधानों का उपयोग करना बेहतर है।

समस्याओं

सिद्धांत रूप में, सब कुछ अच्छा और सुंदर लगता है, लेकिन व्यवहार में, मुझे कई समस्याओं का सामना करना पड़ा। कड़ाई से बोलना, पीसीएल में सभी तर्क करना संभव नहीं था। इसलिए, पृष्ठों के बीच नेविगेशन, डिपेंडेंसी प्रॉपर्टी बनाने के लिए कोड, और कुछ अन्य चीजें विंडोज फोन एप्लिकेशन प्रोजेक्ट में बनी रहीं और इस तरह से परीक्षण बंद नहीं हुए। सैद्धांतिक रूप से, इस कोड के अधिकांश भाग को PCL में स्थानांतरित किया जा सकता है, लेकिन इससे अनुचित (IMHO) निश्चित रूप से अमूर्तता का दोष होगा और परिणामस्वरूप, भविष्य में कोड का समर्थन जटिल हो जाएगा।
एक अन्य समस्या XAML में गुणों को नियंत्रित करने के लिए ViewModels गुणों का बंधन था। बाद के कई विशिष्ट प्रकार ( Brush , Visibility ) हैं जो पीसीएल में उपलब्ध नहीं हैं। रूपांतरण तंत्र के माध्यम से समस्या को खूबसूरती से हल किया गया है , हालांकि, आपको यह याद रखने की आवश्यकता है कि बड़ी संख्या में नियंत्रण के साथ, इस तरह के रूपांतरण से आवेदन धीमा हो सकता है।

एक बात और

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

परिणाम

शेष परीक्षणों में, अधिकांश कार्यक्षमता बंद थी। ViewModels परीक्षण कोड अब वास्तविक परीक्षण मामलों ("यहां क्लिक करें" - "यहां और ऐसे-ऐसे नंबर दर्ज करें" - "अपेक्षित के साथ मूल्य की तुलना करें") जैसा दिखता है।
इस तरह के परीक्षण लिखना डेवलपर्स के लिए इच्छुक परीक्षकों को प्रेरित करने का एक अच्छा तरीका है। और वे क्लिक करने के बजाय कोड लिखने की कृपा कर रहे हैं, और परीक्षण प्रगति पर है :)

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

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

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

चूँकि मैं एक पागल हूँ, इसलिए मैंने तरीकों के 100% से कम कवरेज के मामले में निर्माण को "गिरने" के लिए निर्धारित किया है (यदि नियंत्रित कोड में कम से कम एक विधि होती है, जिसमें लैम्ब्डा अभिव्यक्ति भी शामिल है जो परीक्षण में प्रवेश नहीं करते हैं)। हालांकि सामान्य लोगों के लिए, इस तरह का नियंत्रण शायद बहुत अधिक होगा।
किसी भी मामले में, कोड कवरेज परीक्षणों द्वारा कार्यात्मक कवरेज के साथ संबंध रखता है, और लाल रेखाओं के अध्ययन से अक्सर परीक्षण परिदृश्यों के बारे में विचार प्रेरित होते हैं जिन्हें एन्कोड किया जाना चाहिए।

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