💂🏼 📗 ✊ आपके लिए कोड से कार लिखने के परीक्षण कैसे करें 🏸 🐝 👩🏽‍⚕️

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

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

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

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

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

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

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

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

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

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

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

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

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

- हम कह सकते हैं कि समस्या यह है कि लोगों को इस बात का अंदाजा नहीं है कि सॉफ्टवेयर विकास की प्रक्रिया कैसी चल रही है?

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

यह कहना हमेशा सही नहीं होता है कि जो व्यक्ति परीक्षण पसंद नहीं करता है वह अकुशल डेवलपर है।

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

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

- क्या आपको लगता है कि पायथन गतिशील रूप से टाइप किया गया है और संकलन चरण में कुछ भी नहीं देखता है? क्या इसके साथ अन्य भाषाओं में यह आसान हो सकता है?

- मुझे लगता है, नाटक, और मजबूत। यह प्रकारों के बारे में एक शाश्वत कहानी है, लेकिन टाइप एनोटेशन के आगमन के साथ काम करना आसान हो गया है।

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

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

- इसके बाद क्या होगा? क्या आपको लगता है कि टाइपिंग अधिकतम या न्यूनतम पर होनी चाहिए? डायनामिक कोड में टाइपिंग का संतुलन क्या होना चाहिए?

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

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

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

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

- मैं इस पर आपसे पूरी तरह सहमत हूं। यह केवल यह समझने के लिए रहता है कि किस प्रकार का उपयोग करना है, क्योंकि यह एक अलग अस्पष्ट विषय है।

: «, Haskell , : , . Python , , ».

— . , , legacy- smoke-. . ?

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

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

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

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

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

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

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

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

- आप ऐसे ऑटो-जेनरेट किए गए परीक्षणों पर कितना भरोसा कर सकते हैं? मेरा क्या मतलब है - वे एक विशिष्ट कार्यान्वयन के लिए कितने बंधे हैं, और वे व्यापार तर्क या रीफैक्टरिंग में सामान्य परिवर्तनों के तहत कैसे व्यवहार करेंगे?

- विचार उस कोड को उस रूप में लेना है जिसमें वह अभी है, और इसके आधार पर इस समय वैध परीक्षण उत्पन्न करना है।

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

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

मैं डेवलपर के लिए एक उपकरण प्राप्त करना चाहता हूं, न कि कोड कवरेज बढ़ाने के लिए एक टुकड़ा।

- सफलता मेट्रिक्स क्या हो सकती है? कैसे समझें कि हमने परीक्षण अच्छी तरह से उत्पन्न किए हैं?

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

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

- तकनीकी रूप से यह बता पाना कितना मुश्किल है। एक बहुत कठिन काम की तरह लगता है।

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

मुझे लगता है कि किसी ने भी ऐसा करने की कोशिश नहीं की, क्योंकि यह काम मुश्किल है। अन्यथा, नेटवर्क पर कुछ कलाकृतियां होंगी जैसे कि कोड, विवरण, लेख, या कम से कम उल्लेख है कि ऐसी कोई चीज थी, लेकिन इसे छोड़ दिया गया था।

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

एक फ़ंक्शन में तर्कों के कई समूह हो सकते हैं, तर्कों के लिए रणनीति और इन रणनीतियों के लिए कई परिणाम हो सकते हैं। रणनीतियों की बात करते हुए, मेरा मतलब है कि, हम कहते हैं, हैं if arg_1==1: raise error। इसका मतलब यह है कि कुछ समूह arg_1=1है जिसके लिए फ़ंक्शन हमेशा एक त्रुटि देता है। लेकिन तर्क के साथ, arg_1>2फ़ंक्शन का परिणाम अलग होगा, और एक दूसरा समूह बनाया जाएगा, दूसरी रणनीति।

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

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

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

मुझे नहीं लगता कि किसी दिन सभी प्रकार के मामलों को 100% तक कवर करना संभव होगा, उदाहरण के लिए, Django स्रोत कोड के विशाल कैनवस के लिए। यह श्रमसाध्य लेकिन दिलचस्प है। अब तक मैं बस उत्सुक हूं जहां मुझे पहुंचने के लिए धैर्य और शक्ति है।

- क्या अन्य भाषाओं और क्षेत्रों से कोई उदाहरण हैं जहां यह काम करता है?

- समान कोई ज्ञात नहीं हैं। मुझे लगता है कि क्योंकि एक विशेष उपकरण को काटने की तुलना में परीक्षण लिखना आसान है।

लेकिन मुझे इस बात का अहसास है कि हम जल्द या बाद में जो हम पहले से ही अच्छा कर रहे हैं उसे स्वचालित कर देंगे।

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

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

अगर कुछ बहुत समान था, तो, निश्चित रूप से, कोई भी चीज को अपना सकता है, झांकना।

- क्या आपको लगता है कि पाइथन कोड लिखने की रूपरेखा या तकनीकें एएसटी पेड़ से परीक्षण उत्पन्न करने के कार्य को सरल या जटिल बनाती हैं?

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

- शायद यह किसी प्रकार की तकनीक है - बहुत सारी गतिशीलता, गेटटार का उपयोग - ऐसा कुछ? या यह ठीक काम कर रहा है?

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

- हमने पहले ही कहा है कि ऑटो-जेनरेट किए गए टेस्ट मुख्य रूप से लोगों के लिए हैं। वे लोगों के लिए कितने पठनीय होंगे? प्रत्येक परीक्षण के अंदर बहुत से तर्क होंगे, मुखर? कोड और डेटा के बीच अलगाव कैसा दिखेगा, आप इसे कैसे देखते हैं?

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

एक विधि में अब तक सम्मिलित हैं। यही है, अगर कोई फ़ंक्शन है और इसमें 5 राज्य हैं जो हम जांचना चाहते हैं, तो जब तक कि 5 आरोही फ़ंक्शन के अंदर नहीं जाते हैं।

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

- क्या आप unittest या pytest का समर्थन करते हैं?

- पाइस्टेस्ट। और सिर्फ इसलिए कि मैं अब आउटपुट पर बहुत सारी ऊर्जा खर्च नहीं करना चाहता। पाइस्टेस्ट अच्छा है क्योंकि इसके लिए बहुत सारे प्लगइन्स, डेकोरेटर, विभिन्न मॉडिफ़ायर हैं जो उपयोग करने में आसान हैं।

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

- यह दृष्टिकोण संपत्ति-आधारित परीक्षणों से कितना संबंधित है?

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

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

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

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

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

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

- हमें अगले महत्वपूर्ण बिंदु के बारे में बताएं: प्राप्त परीक्षणों का परीक्षण कैसे करें और आप कितना गारंटी दे सकते हैं कि ये परीक्षण वास्तव में कुछ परीक्षण करते हैं?

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

- आइए अब मॉस्को पायथन कॉन्फ + ++ सम्मेलन की थोड़ी चर्चा करें। हम प्रदर्शन करेंगेपरिकल्पना डेवलपर्स में से एक हमने कई बार उल्लेख किया। आप उससे पूछने में क्या दिलचस्पी लेंगे?

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

मैं परिकल्पना को कैसे देखता हूं, योगदानकर्ताओं को कैसे देखता हूं, के संदर्भ में मैं स्वचालित परीक्षण पीढ़ी के विचारों पर चर्चा करना चाहता हूं। निश्चित रूप से ऐसे स्तर पर परीक्षण में लगे लोगों के पास कुछ विचार हैं या शायद किसी ने पहले से ही कुछ करने की कोशिश की है।

"हम इस पर भरोसा कर रहे हैं जब हम सम्मेलन कार्यक्रम तैयार कर रहे हैं: चर्चा के लिए विषय निर्धारित करने वाली रिपोर्टों के लिए, जिसके दौरान हर किसी को विकास के लिए नए विचार और दिशाएं मिलेंगी।" आप किस रिपोर्ट में जाएंगे?

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

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

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

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

- आप सम्मेलनों में बोलने के लिए समय कहां से निकालते हैं, अपनी खुद की लाइब्रेरियों को लिखें? यह प्रश्न वास्तव में लगातार पॉप अप होता है, बहुत से लोग शिकायत करते हैं कि उनके पास किसी भी चीज़ के लिए समय नहीं है।

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

मैं काम पर अनावश्यक काम नहीं करने की कोशिश करता हूं, ऐसा करने के लिए नहीं जो बाद में मेरे समय के नुकसान को पूरा करेगा।

मान लीजिए, अगर वे मुझे शुक्रवार को तैनात करने के लिए कहते हैं, तो मैं कहता हूं: "दोस्तों, मैं आप सभी से बहुत प्यार करता हूं, आप सभी महान सहयोगी हैं, लेकिन अगर आपको अभी कुछ करने की जरूरत है, तो कृपया खुद को तैनात करें, और मैं घर जाऊंगा। मैं इसे सोमवार को तैनात कर सकता हूं, हम इस बारे में बात कर सकते हैं कि ऐसी स्थिति क्यों हुई है, कि आप शुक्रवार को तैनात करना चाहते हैं। " ग्राहक या प्रबंधकों को यह बताना पहली बार के लिए दर्दनाक हो सकता है, लेकिन बाद में लोगों की आदत हो जाती है, जानने के लिए और शुक्रवार की रात को आपसे बहुत जरूरी काम करने के लिए न कहें। वे समझते हैं कि, सबसे पहले, पिछले शुक्रवार को किसी की मृत्यु नहीं हुई, जब कोई भी बाढ़ में नहीं गया था, और यहां तक कि किसी के पास पैसा नहीं था। मैं कोशिश करता हूं कि मैं ऐसा कुछ न करूं जिससे मुझे नुकसान हो।

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

कभी-कभी आपको खुद पर काबू पाने और बातचीत शुरू करने की आवश्यकता होती है। यह हमेशा संभव नहीं होता है, जागरूकता के एक निश्चित स्तर तक बढ़ने के लिए आवश्यक है कि आप कितने समय तक किस तरह के काम पर खर्च करते हैं, आप जिम्मेदार हैं।

इसलिए, मेरे पास शायद समय है। क्योंकि मैं किसी कार्य को पूरा करने के लिए एक निश्चित संख्या में घंटे लेने के लिए, अपने कार्य समय को अनुकूलित करने का प्रयास करता हूं। उसी समय, मैं समझता हूं कि एक अच्छी संरचना में तकनीकी ऋण और कुछ सुधारों के लिए 1-2 घंटे होने चाहिए।

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

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

कोई रहस्य नहीं है, आपको बस वही करने की ज़रूरत है जो आपको पसंद है, लेकिन साथ ही आपके और परियोजना के आसपास के लोगों को नुकसान पहुंचाए बिना।

पायथन कोड से परीक्षण पीढ़ी को लागू करने के विवरण के साथ-साथ पायथन डेवलपर के कई अन्य कार्यों को हल करने के लिए, मॉस्को पायथन कॉन्फ ++ में आते हैं , जिसे हमने 15 सितंबर को स्थगित कर दिया।

आपके लिए कोड से कार लिखने के परीक्षण कैसे करें

More articles: