🔂 ⛲️ 🤣 हम iOS पर Sberbank Online का परीक्षण कैसे करते हैं 👨🏿‍✈️ 📃 🙇🏼

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

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

लेख के पहले भाग में हम स्वच्छ (गैर-एकीकरण) इकाई परीक्षणों के साथ काम करते समय आने वाली कठिनाइयों से परिचित होंगे, दूसरे भाग में हम यूआई परीक्षणों पर विचार करेंगे। यह जानने के लिए कि हम टेस्ट रन की स्थिरता में सुधार कैसे कर रहे हैं, कैट में आपका स्वागत है।

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

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

इस वर्ष Apple के WWDC अंतर्राष्ट्रीय सम्मेलन में इस मुद्दे पर प्रकाश डाला गया था:

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

यूनिट परीक्षण

निमिष परीक्षणों का सामना करने के लिए, हम निम्नलिखित क्रियाओं का उपयोग करते हैं:

0. हम बुनियादी मानदंडों के अनुसार गुणवत्ता परीक्षण कोड का मूल्यांकन करते हैं: अलगाव, मोका की शुद्धता, आदि। हम नियम का पालन करते हैं: ब्लिंकिंग टेस्ट के साथ, हम टेस्ट कोड बदलते हैं, न कि टेस्ट कोड।

यदि यह आइटम मदद नहीं करता है, तो निम्नानुसार आगे बढ़ें:

1. हम उन परिस्थितियों को ठीक और पुन: उत्पन्न करते हैं जिनके तहत परीक्षण गिरता है;
2. पतन का कारण खोजें;
3. परीक्षण कोड या परीक्षण कोड बदलें;
4. पहले चरण पर जाएं और जांचें कि क्या गिरावट का कारण समाप्त हो गया है।

खेल खेलते हैं

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

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

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

#! /bin/sh x=0 while [ $x -le 100 ]; do xcodebuild -configuration Debug -scheme "TargetScheme" -workspace App.wcworkspace -sdk iphonesimulator -destination "platfrom=iOS Simulator, OS=11.3, name=iPhone 7" test >> "report.txt"; x=$(( $x +1 )); done

एक नियम के रूप में, यह गिरावट को पुन: उत्पन्न करने और अगले चरण पर आगे बढ़ने के लिए पर्याप्त है - दर्ज की गई गिरावट के कारण की पहचान करना।

गिरावट और संभावित समाधान के लिए कारण

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

परीक्षणों के गिरने के कारणों के तीन मुख्य समूह हैं:

खराब इन्सुलेशन

अलगाव से हमारा तात्पर्य एन्कैप्सुलेशन के एक विशेष मामले से है, जिसका नाम है: एक भाषा तंत्र जो कुछ प्रोग्राम घटकों को दूसरों तक पहुंच को प्रतिबंधित करने की अनुमति देता है।

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

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

अतुल्यकालिक कॉल करें

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

 //act [self.testService loadImageFromUrl:@"www.google.ru" handler:^(UIImage * _Nullable image, NSError * _Nullable error) { //assert OCMVerify([cacheMock imageAtPath:OCMOCK_ANY]); OCMVerify([cacheMock dateOfFileAtPath:OCMOCK_ANY]); OCMVerify([imageMock new]); [imageMock stopMocking]; }]; [self waitInterval:0.2];

इस तरह के परीक्षण का परीक्षण करने के लिए, कई दृष्टिकोण हैं:

NSRunLoop चलाएं
waitForExpectationsWithTimeout

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

हमें किसी प्रकार की डेटा प्रोसेसिंग सेवा प्रदान करनी चाहिए। हम यह सत्यापित करना चाहते हैं कि सर्वर से प्रतिक्रिया प्राप्त करने के बाद, यह इस डेटा को आगे की प्रक्रिया के लिए स्थानांतरित करता है।

नेटवर्क पर अनुरोध भेजने के लिए, सेवा क्लाइंट के साथ काम करने के लिए इसका उपयोग करती है।

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

 @interface Service : NSObject @property (nonatomic, strong) id<APIClient> apiClient; @end @protocol APIClient <NSObject> - (void)getDataWithCompletion:(void (^)(id responseJSONData))completion; @end - (void)testRequestAsync { // arrange __auto_type service = [Service new]; service.apiClient = [APIClient new]; XCTestExpectation *expectation = [self expectationWithDescription:@"Request"]; // act id receivedData = nil; [self.service receiveDataWithCompletion:^(id responseJSONData) { receivedData = responseJSONData; [expectation fulfill]; }]; [self waitForExpectationsWithTimeout:10 handler:^(NSError * _Nullable error) { expect(receivedData).notTo.beNil(); expect(error).to.beNil(); }]; }

लेकिन परीक्षण का तुल्यकालिक संस्करण अधिक स्थिर होगा और आपको टाइमआउट के साथ काम करने से छुटकारा दिलाएगा।

उसके लिए हमें एक तुल्यकालिक नकली APIClient की आवश्यकता है

 @interface APIClientMock : NSObject <APIClient> @end @implementation - (void)getDataWithCompletion:(void (^)(id responseJSONData))completion { __auto_type fakeData = @{ @"key" : @"value" }; if (completion != nil) { completion(fakeData); } } @end

तब परीक्षण सरल दिखाई देगा और अधिक स्थिर काम करेगा

 - (void)testRequestSync { // arrange __auto_type service = [Service new]; service.apiClient = [APIClientMock new]; // act id receivedData = nil; [self.service receiveDataWithCompletion:^(id responseJSONData) { receivedData = responseJSONData; }]; expect(receivedData).notTo.beNil(); expect(error).to.beNil(); }

एसिंक्रोनस ऑपरेशन को एक अलग इकाई को एनकैप्सुलेट करके अलग किया जा सकता है, जिसे स्वतंत्र रूप से परीक्षण किया जा सकता है। शेष तर्क को समकालिक रूप से जांचने की आवश्यकता है। यह दृष्टिकोण अतुल्यकालिक द्वारा लाए गए अधिकांश नुकसानों से बचाएगा।

एक विकल्प के रूप में, पृष्ठभूमि थ्रेड से UI परत को अपडेट करने के मामले में, आप जांच सकते हैं कि क्या हम मुख्य थ्रेड में हैं और यदि हम परीक्षण से कॉल करते हैं, तो क्या होगा:

 func performUIUpdate(using closure: @escaping () -> Void) { // If we are already on the main thread, execute the closure directly if Thread.isMainThread { closure() } else { DispatchQueue.main.async(execute: closure) } }

विस्तृत विवरण के लिए, डी। सैंडल का लेख देखें।

आपके नियंत्रण से परे परीक्षण कोड
अक्सर हम निम्नलिखित बातों को भूल जाते हैं:

विधियों का कार्यान्वयन आवेदन के स्थानीयकरण पर निर्भर हो सकता है,
एसडीके में निजी विधियां हैं जिन्हें फ्रेमवर्क कक्षाओं द्वारा बुलाया जा सकता है,
विधियों का कार्यान्वयन एसडीके के संस्करण पर निर्भर हो सकता है

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

इसके साथ, हम यूनिट परीक्षण के लिए समर्पित Sberbank Online iOS एप्लिकेशन के स्वचालित परीक्षण पर लेख के पहले भाग को पूरा करना चाहते हैं।

लेख के दूसरे भाग में, हम उन समस्याओं के बारे में बात करेंगे जो 1500 यूआई परीक्षण लिखते समय हुईं, साथ ही साथ उन पर काबू पाने के लिए व्यंजनों।

यह लेख रेगो के साथ लिखा गया था - एंटोन व्लासोव, विकास के प्रमुख और आईओएस डेवलपर।

हम iOS पर Sberbank Online का परीक्षण कैसे करते हैं

यूनिट परीक्षण

खेल खेलते हैं

गिरावट और संभावित समाधान के लिए कारण

More articles: