क्या इकाई परीक्षणों में फ़ाइल सामग्री / एन्कोडिंग की जाँच करना 'बुरा व्यवहार' माना जाता है?


84

थोड़ा सा संदर्भ: पहले आज मुझे कुछ एसक्यूएल कोड को अपडेट करना था जो मेरे एक अन्य सहयोगी ने प्रदान किया था, और चूंकि यह एक बहुत बड़ी स्क्रिप्ट है, इसलिए इसे एक अलग फाइल के रूप में संग्रहीत किया जाता है (जिसे तब पढ़ा जाता है और रनटाइम पर निष्पादित किया जाता है)। ऐसा करते समय मैंने गलती से दो बगों को फिर से पाला था, कुछ महीने पहले, अर्थात्:

  • जिस भी कारण से ASCII फाइल UTF-16 में कूटबद्ध की गई थी (सहकर्मी ने मुझे वह फाइल ईमेल की थी, जिसके कारण यह हो सकता है)।
  • स्क्रिप्ट प्रारंभिक SETविवरणों को याद कर रही थी (उत्पादन पर कुछ ड्राइवर चीजों के कारण आवश्यक है, लेकिन स्थानीय रूप से एक साफ इंस्टॉल पर नहीं)।

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

हालाँकि जब मैंने इस कोड को एक अन्य सहयोगी (जो हमारी टीम लीड भी है) को आगे बढ़ाया और मुझसे कहा कि मुझे इन चीजों को दोबारा नहीं बनाना चाहिए:

"ये चीजें यूनिट परीक्षणों में शामिल नहीं हैं"

"इकाई परीक्षणों का उपयोग केवल आपके कोड के प्रवाह की जांच के लिए किया जाना चाहिए"

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



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

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

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

5
परीक्षण के बजाय कि फ़ाइल में सही सामग्री और एन्कोडिंग है, यह परीक्षण क्यों नहीं करता है कि यह काम करता है ?
इमीबिस

जवाबों:


156

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

मैं इस बात पर अधिक ध्यान केंद्रित नहीं करूंगा कि यूनिट टेस्ट क्या है या क्या नहीं है और यह महसूस करें कि अगर इसकी इंटीग्रेशन टेस्ट हो तो भी टेस्ट में वैल्यू हो सकती है।


टिप्पणियाँ विस्तारित चर्चा के लिए नहीं हैं; इस वार्तालाप को बातचीत में स्थानांतरित कर दिया गया है ।
थॉमस ओवेन्स

36

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

मैं क्या समस्या हल करने की कोशिश कर रहा हूं?

विवरण द्वारा, आपको यह सत्यापित करने की आवश्यकता है कि कोई भी डेटाबेस स्क्रिप्ट कुछ मानकों का अनुपालन करती है।

समस्या को हल करने के लिए कौन से उपकरण / प्रक्रियाएँ उपलब्ध हैं?

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

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

इकाई परीक्षण केवल आपकी वर्तमान फ़ाइल के लिए समस्या का समाधान करता है।

मैं उपकरण की आवश्यकता को कैसे बताऊं?

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

आपकी टीम लीड में कुछ ऐसे विचार हो सकते हैं जिन पर आपने (या मैंने) विचार नहीं किया है, जो समस्या को अधिक सही तरीके से संबोधित कर सकते हैं।


21
लागत बनाम जोखिम पर चर्चा करते समय, यह ध्यान रखना महत्वपूर्ण होगा कि पहले से ही हल किए गए बगों को फिर से प्रस्तुत करने के कारण पहले से ही खोए हुए समय का कारण है। यह अकेले सत्यापन को स्वचालित करने का एक मजबूत तर्क है। +1
jpmc26

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

1
@BerinLoritsch तकनीकी रूप से, यह एक इकाई परीक्षण नहीं है जो मैं वास्तव में जानना चाहूंगा कि आप इस "दावे" को किस आधार पर लेते हैं। जहां तक ​​मैं बता सकता हूं, यूनिट परीक्षणों की कोई एक आधिकारिक परिभाषा नहीं है और हर कोई "क्या वे हैं " का अपना विचार है ।
gbr

2
@ ग्रब डेवलपर्स के बीच एक अनौपचारिक समझौता है कि यूनिट परीक्षण ऐसे परीक्षण हैं जो बाहरी प्रणालियों से अलगाव में चलाए जाते हैं। वे केवल कोड का ही परीक्षण करते हैं , फाइलों, डेटाबेस या अन्य बाहरी सेवाओं के साथ बातचीत नहीं करते। विकिपीडिया इस समझ को प्रलेखित करता है: en.wikipedia.org/wiki/Unit_testing#External_work
jpmc26

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

19

"यूनिट टेस्ट" फ़ाइलों तक पहुंचने वाले परीक्षणों को कॉल करना बुरा व्यवहार है।

वह: "ये चीजें इकाई परीक्षणों में नहीं हैं"

आप: "समझ में आता है, लेकिन मैं उन्हें लगाने के लिए एक बेहतर जगह नहीं ढूंढ सका। वे कहाँ हैं?"

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

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


2
"यूनिट टेस्ट" फ़ाइलों का उपयोग करने वाले परीक्षणों को कॉल करना बुरा व्यवहार है। यहां जिस फाइल को एक्सेस किया जा रहा है वह सोर्स फाइल है। यह किसी भी स्रोत फ़ाइल (इसे पार्स करने के लिए) के रूप में बस के रूप में उपयोग किया जाएगा। तथ्य यह है कि परीक्षण संभवतः "यूनिट" की उसी भाषा में नहीं किया जाएगा जिसे चेक किया जा रहा है (SQL) इसे अपरंपरागत बनाता है लेकिन इकाई परीक्षण के रूप में इसके वर्गीकरण को प्रभावित नहीं करना चाहिए। जारी है ...
gbr

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

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

2
@Warbo यह है फ़ाइलें (सामान्य रूप में) का उपयोग करने के लिए एक बुरा व्यवहार, और (सबसे महत्वपूर्ण) कारण यह है कि वे अगर वे शामिल "GB का एक परतदार एनएफएस लिंक पर पढ़ें" धीमी गति से नहीं कर रहे हैं, वे यदि धीमी गति से कर रहे हैं, जैसे माइकल पंख के हवाले , वे 1/10 सेकंड का समय लेते हैं। ऐसा इसलिए है क्योंकि आप अपने परीक्षणों को यथासंभव अधिक से अधिक चलाना चाहते हैं, आदर्श रूप से आईडीई में आपके द्वारा किए गए हर बदलाव पर, और जब आपके पास उनमें से बहुत कुछ (जैसा कि आपको होना चाहिए) यहां तक ​​कि 10 सेकंड का समय घंटों तक कम करते हैं। (जारी है ...)
gbr

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

14

माइकल फेदर्स ने अपनी पुस्तक वर्किंग इफेक्टिवली विथ लेगेसी कोड में यह कहा है:

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

क्या आपका परीक्षण त्रुटियों को जल्दी से स्थानीय करने और तेजी से चलाने में मदद करेगा? यदि हाँ, तो करें! यदि नहीं, तो नहीं! यह इतना सरल है!

कहा जा रहा है, आप अन्य लोगों के साथ एक वातावरण में काम कर रहे हैं और उनके साथ मिलना है। आपको इसे अपने तरीके से करना पड़ सकता है, भले ही आप निजी तौर पर इससे असहमत हों।


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

1
@gbr यदि परीक्षण के परिणाम सटीक हैं, तो केवल एक चीज जो महत्वपूर्ण है वह यह है कि यह कितनी जल्दी चलता है। अगर मेरे पास 100 परीक्षण हैं जो प्रत्येक 0.1 के तहत चलते हैं, तो कुल मिलाकर वे 10 से कम समय में चलेंगे। मैं उन्हें बार-बार चलाकर खुश हूं। अगर मेरे पास 1000 परीक्षण हैं, तो वे 1m40s तक ले जाएंगे। यह बहुत लंबा है, मैं उन्हें बार-बार नहीं चलाऊंगा, लेकिन 100 टेस्ट के छोटे समूह के साथ बदलाव करने के बाद मैं उन्हें चलाऊंगा। मुझे परवाह नहीं है अगर यह तकनीकी रूप से एक स्वीकृति परीक्षण या कुछ और है। अगर मुझे जल्द ही त्रुटियों को खोजने में मदद मिलती है, तो मैं इसे शब्दार्थ की परवाह किए बिना करूँगा। एक परीक्षण केवल मूल्य प्रदान करता है जब यह चलाया जाता है।
सीजे डेनिस

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

@gbr वह इकाई परीक्षणों को पुनर्परिभाषित नहीं कर रहा है, वह कह रहा है कि समावेश के लिए आपकी कसौटी नहीं होनी चाहिए। आपकी कसौटी उपयोगिता होनी चाहिए, और यही वह परिभाषित कर रहा है।
सीजे डेनिस

मैंने उस अनुभाग को फिर से पढ़ा; मुझे यकीन नहीं है, यह मेरे लिए स्पष्ट नहीं है अगर इसका मतलब (एक प्रकार का) परिभाषा या सिर्फ एक मानदंड है। लेकिन वास्तव में " क्या यह हमें त्रुटियों को जल्दी से स्थानीय बनाने में मदद कर सकता है" अलगाव के बारे में जो कुछ भी वह पहले कहता है उसे बहुत अच्छी तरह से समझा सकता है। इसलिए मैंने कुछ नहीं के बारे में एक उपद्रव किया है (हालांकि आपके जवाब को अभी भी गलत समझा जा सकता है)
gbr

10

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

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

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


4

एक इकाई परीक्षण एक विधि या कोड की 'इकाई' के परीक्षण के बारे में है। आप अपने सॉफ़्टवेयर में तर्क और कोड के सबसे छोटे समूह का परीक्षण कर रहे हैं।

बाद में, जब आप अन्य इकाइयों के साथ जुड़ेंगे तो आप एकीकरण परीक्षण करेंगे।

मुझे उम्मीद है कि आपकी टीम लीड ने आपकी पहल को प्रोत्साहित किया और वैकल्पिक सुझाव देने चाहिए। आपके पास निश्चित रूप से सही विचार है।

आपकी SQL किसी भी निचली पीढ़ी की भाषा जैसे C # या Java की तरह कोड है और इसे इस तरह से परीक्षण किया जाना चाहिए। और सत्यापन और सत्यापन सभी परीक्षण स्तरों से संबंधित हैं। इसलिए एन्कोडिंग और SET स्टेटमेंट शामिल हैं, लेकिन विशेष रूप से आवश्यक रूप से परीक्षण नहीं किया गया है। आम सामान जैसे लाइन एंडिंग या एनक्लोजिंग आप आमतौर पर एक एससीएम हुक या सुविधा का उपयोग कर सकते हैं।

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

बात यह है ... वाक्यविन्यास त्रुटियां, एक 'यूनिट' के अंदर गायब स्टेटमेंट या लॉजिक ब्लॉक आमतौर पर परीक्षण नहीं किए जाते हैं। आप विभिन्न संयोजनों में इकाई के इनपुट और आउटपुट का परीक्षण कर रहे हैं, कई संभावनाओं का परीक्षण कर सकते हैं जो उत्पन्न हो सकते हैं।

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


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

@Warbo - मैं इसे (लेकिन नहीं) एकीकरण परीक्षण के करीब कहूंगा। यूनिट परीक्षण के लिए अत्यधिक या बड़े पैमाने पर कुछ भी करने की आवश्यकता नहीं होती है। यूनिट परीक्षण छोटे और तेज होने चाहिए। वास्तव में कार्यक्षमता के परीक्षण से आप जो वर्णन करते हैं, उसकी ओर जाता है .. फ्रैगाइल परीक्षण वे हैं जो 1. बड़े होते हैं या जितना करना चाहिए उससे अधिक करते हैं। 2. अत्यधिक युग्मित 3. एक भी जिम्मेदारी नहीं है।
रॉस

3

यदि आपके पास ऐसी फाइलें हैं जो आपके उत्पाद का हिस्सा बन जाती हैं, तो उनकी सामग्री सही होनी चाहिए। कोई कारण नहीं कि आप इसे सत्यापित नहीं करेंगे। उदाहरण के लिए यदि आपको किसी फ़ोल्डर में छह 1024x 1024 चित्र चाहिए, तो हर तरह से एक इकाई परीक्षण लिखें जो आपके पास ठीक है।

लेकिन आपके पास शायद फाइलें नहीं हैं, आपके पास कुछ कोड भी हैं जो फाइलें पढ़ते हैं। आप उस कोड के लिए एक यूनिट टेस्ट लिख सकते हैं। ऊपर दिए गए उदाहरण में, छह छवियों में से एक को पढ़ने के लिए फ़ंक्शन मेमोरी में 1024 x 1024 छवि लौटाता है (या जो कुछ भी उत्पादन करना चाहिए था)।

वैसे भी, यह एक इकाई परीक्षण नहीं हो सकता है, लेकिन यह एक उपयोगी परीक्षण है। और अगर आप एक यूनिट टेस्ट फ्रेमवर्क का उपयोग करते हैं जो आपको एक उपयोगी परीक्षण करने की अनुमति देता है (जो कि यूनिट टेस्ट नहीं है), तो यूनिट टेस्ट फ्रेमवर्क का उपयोग क्यों नहीं करें?


2

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

git add -p

यह एक पाठ फ़ाइल में प्रत्येक परिवर्तन के लिए काम कर रहे निर्देशिका आपसे पूछेगा कि क्या आप वास्तव में इसे रखना चाहते हैं। उदाहरण के लिए, आप उन "प्रारंभिक SETकथनों" को हटा सकते हैं ।

यदि किसी संपूर्ण फ़ाइल की एन्कोडिंग बदल जाती है, तो अलग-अलग होने पर भी कुछ घटित होगा: एल्गोरिथ्म पुरानी और नई फ़ाइल को अलग करने में विफल होगा, और इसलिए इसमें git add -pकुछ भी नहीं जोड़ा जाएगा। यह तब किसी भी कमेटी के नाम से पहले की गई दूसरी कमांड में दिखाई देगा

git status

यहाँ आप लाल रंग में हाइलाइट फ़ाइल देखना चाहते हैं, जो यह दर्शाता है कि कर रहे हैं बदल जाता है। जाँच क्यों इन में git add -pयह जल्दी से समस्या स्पष्ट कर देगा नहीं किया।


प्रार्थना बताओ, यह कैसे किसी भी भविष्य के देव को उसी समस्या से बचने में मदद करता है? ... स्वचालित परीक्षणों (भी अभिकथन और डिजाइन-बाय-कॉन्ट्रैक्ट के बारे में मान्य) के बारे में बात यह है कि वे, अच्छी तरह से, erm, स्वचालित हैं
vaxquis

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

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

@vaxquis No, नहीं! सीट बेल्ट उस तरह के परीक्षणों के अनुरूप होते हैं जो समझ में आते हैं: वे उन स्थितियों की एक विस्तृत सरणी को पकड़ते हैं जो दुर्घटना से होने की संभावना है। फ़ाइल-एन्कोडिंग पर एक परीक्षण एक रोबोट के अनुरूप होगा जो आपके आस-पास का अनुसरण करता है और आपको अपने नाक के ऊपर सेम भरकर अपने आप को आराम करने से रोकता है।
लेफ्टरनैबाउट

ओ पी के अनुसार, गलत प्रारूप में फ़ाइलों हुआ है दो बार पहले से ही है, तो जाहिरा तौर पर वे कर रहे हैं दुर्घटना से होने की संभावना।
gnasher729 18

1

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


1
केवल रनटाइम के दौरान असफल होना इसे एक मजबूत ऐप कैसे बनाता है? निश्चित रूप से, समस्या के स्रोत के पास रनटाइम चेक करना भी उपयुक्त हो सकता है, लेकिन अगर आप रनटाइम समस्याओं का कारण बनने से पहले गलतियों का पता लगा सकते हैं , तो यह बहुत बेहतर है, क्या आपको नहीं लगता है? क्या आप वाकई स्वचालित परीक्षण से परिचित हैं?
gbr

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

1
आपकी रणनीति में यूनिट परीक्षण और सामान्य रूप से स्वचालित परीक्षण के साथ (लगभग) कुछ भी नहीं है, यह अलग-अलग उपयोगों के साथ एक अलग बात है।
gbr

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

1
@ Dr.GianluigiZaneZanettini बाह ... मैं हारता हूं ... जैसा कि मैंने इसे देखा, टिप्पणियों में आपके "स्पष्टीकरण" के बाद, आपका जवाब सबसे अच्छा था, ऑफ-टॉपिक (प्रश्न का उत्तर नहीं), लेकिन वास्तव में, जैसा कि यह खड़ा है, यह स्पष्ट गलत है! अतिरिक्त परीक्षण लिखने की आवश्यकता नहीं है ??? मेरे पास इसे डाउनवोट करने के लिए पर्याप्त प्रतिष्ठा नहीं है, लेकिन मानो मैंने ऐसा किया है। और मुझे नहीं लगता कि इस बातचीत को जारी रखने में बहुत मूल्य है।
Gbr

1

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

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

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


1
लेखक कहीं भी यह नहीं कहता है कि एसक्यूएल स्क्रिप्ट कुछ परीक्षण का एक हिस्सा है, आपको लगता है कि यह प्रश्न गलत है
gbr

समझना मुश्किल है, मुझे लगता है कि एसक्यूएल स्क्रिप्ट परीक्षण का हिस्सा है।
18:22 बजे एच 22

आपकी टिप्पणी "समझने में मुश्किल है" ...
gbr

समझना मुश्किल। प्रश्न को नीचा दिखाना।
7:22 बजे h22

1

सबसे पहले - परीक्षणों का एक उद्देश्य मुद्दों को अपने कोड में आवर्ती होने से रोकना है - इसलिए आपको पूरी तरह से इस प्रकृति के परीक्षण लिखना चाहिए

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

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

मैंने अतीत में इस तरह के परीक्षण का बड़े पैमाने पर उपयोग किया है - उन्होंने हमें दर्द का एक अच्छा हिस्सा बचा लिया है।


और अगर कोई मुझे समझाने की परवाह करेगा कि मैं इसकी सराहना करूंगा
मर्फ़

1

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

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

यह सुनिश्चित करने के लिए हमेशा समझदारी है कि किसी भी दोष को पेश किया जा सकता है जिसे विकास चक्र में जल्द से जल्द पता लगाया जा सकता है, और ऐसा करने के लिए फायदेमंद है जो दोष के स्रोत की पहचान करना आसान बनाता है ताकि यह जल्दी से हो सके ठीक कर दिया।

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.