इकाई परीक्षण लिखते समय सामान्य गलतियाँ। यांडेक्स व्याख्यान

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


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

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

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

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



चीनी कहावत चित्रलिपि में लिखी गई है कि एक हज़ार की यात्रा एक कदम से शुरू होती है। ऐसा लगता है कि इस कहावत का ऐसा कोई उपमा है।

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



हमें परीक्षणों की आवश्यकता क्यों है?

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

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

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

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



यह मेरी पूरी रिपोर्ट का सामान्य विचार है। आप पहली पंक्ति दिखा सकते हैं और छोड़ सकते हैं।

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

विशेष रूप से, नीचे दो पंक्तियाँ किसी भी कोड को संदर्भित करती हैं, ऐसा लगता है।

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

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

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



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

^{_{गिटहब लिंक}}

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

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

no_action_or_assertion

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

long_name

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

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

older_prefix

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

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



मैं वास्तव में GitHub पर टेस्ट स्मेल आईडी पढ़ता हूं। लिंक नीचे है, आप चल सकते हैं और उपयोग कर सकते हैं।

multiple_asserts

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

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

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

many_tests_in_one

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

repeating_setup

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

एक परीक्षण वर्ग जिसमें शुरुआत में समान विधियों को निष्पादित किया जाता है। यह थोड़ा सा लगता है, लेकिन हर परीक्षण विधि में यह कचरा मौजूद होता है। और यदि यह सभी परीक्षण विधियों के लिए सामान्य है, तो इसे क्यों न तो कंस्ट्रक्टर में या ब्लॉक से पहले या JUnit 5 में प्रत्येक ब्लॉक से पहले खींचें। यदि आप ऐसा करते हैं, तो प्रत्येक विधि की पठनीयता में सुधार होगा, साथ ही आपको DRY पाप से छुटकारा मिलेगा। इस तरह के परीक्षण बनाए रखने में आसान होते हैं और पढ़ने में आसान होते हैं।



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

बिना सोचे समझे

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

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

tread_sleep

एक क्लासिक समस्या जो डेवलपर्स का सामना करती है जब किसी प्रकार के अतुल्यकालिक कोड का परीक्षण करने की कोशिश की जाती है। यह है कि मैंने परीक्षण में कुछ किया, और तब तक मुझे इंतजार करना होगा जब तक कि यह पूरा न हो जाए। कैसे बनाये? थ्रेड.स्लीप (), निश्चित रूप से।

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

थ्रेड.स्लीप () बहुत दर्द है। इस तथ्य के अलावा कि यह परीक्षणों की विश्वसनीयता को बिगड़ता है, क्योंकि यह उन्हें उपकरणों पर अलग-अलग समय के कारण रोने की अनुमति देता है, यह आपके परीक्षणों के निष्पादन को धीमा कर देता है। कौन चाहेगा कि उसकी इकाई परीक्षण, जिसे मिलीसेकंड में निष्पादित किया जाना चाहिए, पांच सेकंड के लिए चलेगा, क्योंकि मैंने चलने वाली नींद निर्धारित की है?

modify_global

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

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

@VisibleForTesting

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

सामान्य तौर पर, आपको उत्पादन के समान इनपुट और आउटपुट के माध्यम से अपनी कक्षाओं का परीक्षण करना चाहिए। केवल परीक्षणों के लिए किसी भी तरीके तक पहुंच नहीं होनी चाहिए।



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

unnecessary_android_test

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

unnecessary_robolectric

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

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

मैं अब आपको बोर नहीं करूंगा। आपके पास कितनी खुशबू है? अब तक, अधिकतम सात। चैनल की सदस्यता लें, सितारे लगाएं।