क्या मुझे सब कुछ परीक्षण करने की आवश्यकता है?

Question

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

क्या स्थैतिक पृष्ठों सहित मेरे आवेदन के प्रत्येक भाग का परीक्षण करना आवश्यक है ?

Comments

यह वास्तव में रेल के सवाल पर माणिक नहीं है। यह एक टीडीडी प्रश्न से अधिक है।

— जॉन स्ट्रियर

@JonStrayer: है ना? क्या आप निश्चित हैं कि इसका उत्तर RoR के लिए .NET जैसा ही होगा? मेरा सुझाव है कि डिजाइन द्वारा RoR ने जानबूझकर परीक्षण की लागत को कम कर दिया है, जबकि संकलक के रूप में टाइप-सेफ्टी नहीं होने से बड़े पैमाने पर परीक्षण का लाभ बढ़ जाता है।

— पीडीआर

किसी कारण के लिए, यह सवाल मुझे कप्तान नीरो चिल्लाते हुए एक छवि मैक्रो पोस्ट करना चाहता है "टेस्ट ईवरथिंग!"

— मेसन व्हीलर

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

— ZJR

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

— इवान प्लाइस

Answer 1

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

तो, इस बात को ध्यान में रखते हुए, स्थैतिक पृष्ठ का व्यवहार क्या है और इंटरफ़ेस क्या है?

मेरी पहली प्रतिक्रिया "कोई नहीं" और "कोई नहीं" होगी।

Comments

तो स्थैतिक पृष्ठों के लिए कोई परीक्षण नहीं?

— मट्टियो पगलियाज़ी

TDD, डिजाइन के बारे में एक हद तक है। लेकिन आपको अभी भी एक वास्तुकला की आवश्यकता है। मन में एक वास्तुकला के बिना, यह कल्पना करना मुश्किल है कि कोई कैसे परीक्षणों के एक समूह से बाहर बढ़ेगा।

— रॉबर्ट हार्वे

@MatteoPagliazzi परीक्षण के स्तर (इकाई परीक्षण / एकीकरण परीक्षण / आदि) के आधार पर, शायद एक या दो, स्थैतिक पृष्ठों की पुष्टि के लिए सुलभ हैं। लेकिन यह यूनिट परीक्षणों के लिए बहुत उच्च-स्तर है।

— इजाकाता

@RobertHarvey मैंने यह नहीं कहा कि कुछ भी परीक्षण न करें। मैंने कहा कि स्थैतिक पृष्ठों का परीक्षण न करें।

— जॉन स्ट्रायर

@JonStrayer: TDD'ers डिजाइन के लिए कुछ जादुई अमृत के रूप में TDD धारण करते हैं; मैं माफी माँगता हूँ अगर तुम क्या मतलब नहीं है। :)

— रॉबर्ट हार्वे

Answer 2

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

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

सामान्य IMO में इन सवालों का जवाब देना लगभग असंभव है।

मुझे लगता है कि इस मामले में परीक्षण करने की क्षमता को संरक्षित करना अधिक महत्वपूर्ण है कि कुछ विशेषता मूल रूप से एहसास होने की तुलना में अधिक महत्वपूर्ण हो जाती है।

Comments

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

— गॉर्डन गुस्ताफसन

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

— माइकल डुरंट

Answer 3

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

Comments

"तब आपको विश्वास हो सकता है कि नया कोड जोड़ने से इन-प्लेस कोड को काम छोड़ने का कारण नहीं बनता है" इस तरह से मुझे नए तरीकों को जोड़ने से पहले और कोड में लिखे किसी भी टुकड़े को नहीं छूना चाहिए?

— मट्टेयो पगलियाज़ी

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

— ब्रूस एडगर

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

— डेवार्डी

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

— एंडी

Answer 4

हां, आपको हर चीज का परीक्षण करना चाहिए ...

आप हर चीज के लिए स्वचालित परीक्षण लिखने में सक्षम नहीं होंगे। अपने स्थिर पृष्ठों के लिए, सेलेनियम http://seleniumhq.org/ का उपयोग करके सुनिश्चित करें कि चीजें सही हैं।

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

Comments

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

— शिलेस

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

— एंडी

Answer 5

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

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

Answer 6

अगर उस तरह से लिखा जाए तो टीडीडी टेस्ट्स भी विशिष्ट हो सकते हैं। परीक्षण विधियों के नाम एक व्यावसायिक उपयोगकर्ता के लिए समझ में आने चाहिए।

Answer 7

जैसा कि अन्य ने उल्लेख किया है, रूबी ऑन रेल्स टेस्टिंग में यह (अधिकांश) अन्य भाषाओं की तुलना में कहीं अधिक महत्वपूर्ण है। यह एक संकलक की कमी के कारण है।

जैसे बोली डेल्फी , सी ++, VB.NET , आदि ... भाषा संकलित किए जाते हैं, और अपने संकलक ऐसी पद्धति के लिए कॉल में लेखन के रूप में mistkes का एक बहुत ऊपर ले जाएगा। रूबी ऑन रेल्स में आपको केवल तभी पता चलेगा कि आपके कोड में कोई टाइपो या कोई गलती है अगर कोड की विशेष लाइन चलाई जाती है या आप एक IDE का उपयोग कर रहे हैं जो दृश्य चेतावनी दिखाता है।

के रूप में हर एक कोड की लाइन महत्वपूर्ण है (अन्यथा यह वहाँ नहीं होगा) आपको अपने लिखे हर तरीके का परीक्षण करना चाहिए। यदि आप कुछ मूल TBDD टूल का अनुसरण करते हैं तो यह बहुत सरल है।

मैंने पाया है कि रयान बेट्स ' रेल कास्ट पर मैं कैसे परीक्षण मेरे लिए अमूल्य था और वास्तव में TBDD की सादगी पर प्रकाश डाला अगर सही ढंग से किया।

Answer 8

यदि आप सही मायने में TDD कार्यप्रणाली का उपयोग कर रहे हैं, तो आप पहले इकाई परीक्षण के बिना कोड नहीं लिखते हैं जिसे आप पास बनाने की कोशिश कर रहे हैं।

Comments

हां ... लेकिन एक स्थिर पृष्ठ में उदाहरण के लिए मुझे क्या परीक्षण करना चाहिए? इसका अस्तित्व? वह सामग्री और लिंक मौजूद हैं? शायद मैं गलत हूँ, लेकिन यह समय की बर्बादी लगती है ...

— माटेयो पगलियाज़ि

मुझे लगता है कि TDD पद्धति आपके तर्क पर लागू होती है। क्या आपका स्थिर पृष्ठ html फ़ाइल है? एक MVC दृश्य जो कभी नहीं बदलता है? यदि बाद का मामला मुझे लगता है कि आप परीक्षण कर सकते हैं कि आपका नियंत्रक उचित दृश्य लौटाता है। मुझे लगता है कि अधिक महत्वपूर्ण बात यह याद रखना है कि टीडीडी को आपके विनिर्देशन के खिलाफ विकसित करने में मदद करनी चाहिए न कि केवल "परीक्षण" ...

— wessiyad

मुझे लगता है कि आप केवल एक स्थिर पृष्ठ की रूपरेखा के घटक के साथ सेवा कर सकते हैं। यदि आपका कोई भी तरीका उस पृष्ठ को नहीं छू रहा है, तो वास्तव में परीक्षण करने के लिए कुछ भी नहीं है। आपको रेल का परीक्षण करने की भी आवश्यकता नहीं है। मुझे लगता है कि किसी ने इसे कवर किया है।

— एरिक रेपेन

Answer 9

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

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

लेकिन अप्रत्याशित जुड़े निर्भरता की विशाल श्रृंखला गंदे डिजाइन के उत्पाद नहीं हैं?

तो कौन सा है?

यहाँ एक विचार है। डिजाइन पैटर्न से ऑब्जेक्ट-ओरिएंटेड डिज़ाइन के निम्नलिखित दो सिद्धांतों पर विचार करके पहले स्थान पर निर्भरता की विशाल जटिल श्रृंखला नहीं है:

"एक अंतरफलक के लिए कार्यक्रम, एक कार्यान्वयन नहीं"

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

तथा:

"वर्ग विरासत पर अनुकूल वस्तु रचना"

डमी कौन है? वह व्यक्ति जिसने 30 वर्ग की तरह एक जटिल कैस्केडिंग वंशानुक्रम योजना में एक वर्ग के लिए कुछ किया, जिसके परिणामस्वरूप फ्रिंज केस टूट गया, या देव जो पहली बार उस वास्तुकला के साथ आए थे? टीडीडी आपको क्लास पीसा के उस झुके हुए टॉवर के अंदर के मुद्दों की तह तक जाने में मदद कर सकता है, जितनी जल्दी आप बिना कर सकते थे, लेकिन क्या इससे अगली बार उस कोड आपदा के समापन बिंदुओं में से एक को संशोधित करने का प्रयास करने में कोई कम दर्दनाक नहीं है?

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

Answer 10

प्रश्न का उत्तर देने के लिए, "यहां क्या गलत हो सकता है" के बारे में सोचें। विशेष रूप से, यदि आप "कोड" (मार्कअप / जो कुछ भी) बदलते हैं, तो आपको कैसे विश्वास होगा कि आपने पृष्ठ को नहीं तोड़ा है। ठीक है, एक स्थैतिक पृष्ठ के लिए:

• यह प्रस्तुत करना नहीं हो सकता है
• यह गलत तरीके से प्रस्तुत कर सकता है
• जेएस लोड नहीं हो सकता है
• छवियों के लिए पथ काम नहीं कर सकते हैं
• लिंक टूट सकते हैं

व्यक्तिगत रूप से, मैं सुझाऊंगा:

• एक सेलेनियम [1] परीक्षण लिखें जो पृष्ठ पर आपके द्वारा अपेक्षित एक स्ट्रिंग के लिए जाँच करता है (यदि संभव हो तो नीचे के पास)। यह पुष्टि करता है कि यह प्रतिपादन करता है।
• जांचें कि कोई जेएस त्रुटियां नहीं हैं (मुझे लगता है कि सेलेनियम यह अनुमति देता है)
• html सत्यापनकर्ता के माध्यम से स्थैतिक पृष्ठों को चलाएं, और यदि संभव हो तो, एक लिंक चेकर।
• मुझे जेएस को मान्य करने के लिए एक उपकरण नहीं मिला, लेकिन आपको jslint या jshint के साथ सफलता मिल सकती है।

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

Answer 11

बस सभी पहले से ही उत्कृष्ट उत्तरों को जोड़ने के लिए, यहाँ मेरी सोच है कि क्या परीक्षण करना है, और क्या परीक्षण नहीं करना है:

परीक्षण करें:

• व्यापार का तर्क
• आवेदन तर्क
• कार्यक्षमता
• व्यवहार,
• इसलिए, सब कुछ, वास्तव में, को छोड़कर :

परीक्षण न करें:

• स्थिरांक
• प्रदर्शन

इसलिए ऐसा परीक्षण होने का कोई मतलब नहीं है जो कहता है:

assert wibble = 3

और कुछ कोड जो कहता है

wibble = 3

और प्रेजेंटेशनल चीजों का परीक्षण करने का भी कोई मतलब नहीं है, जैसे कि आइकन पेरिविंक ब्लू में है, आपने शीर्षकों के लिए किस फ़ॉन्ट का उपयोग किया है, और इसी तरह ...

तो, आप पूछते हैं, "क्या मुझे स्थैतिक पृष्ठों का परीक्षण करना चाहिए", और जवाब है: आप उन्हें इनोफ़ार का परीक्षण करें क्योंकि वे आपकी साइट की कार्यक्षमता, व्यावसायिक तर्क या व्यवहार का हिस्सा हैं।

इसलिए, हमारे ऐप में, हमारे पास एक परीक्षण है जो यह जांचता है कि साइट के हर हिस्से से नियम और शर्तें उपलब्ध हैं - अनाम उपयोगकर्ताओं के लिए, लॉग-इन उपयोगकर्ताओं के लिए, डैशबोर्ड से, ऐप स्क्रीन आदि के अंदर। प्रत्येक पृष्ठ पर "नियम और शर्तें" नामक एक लिंक, जो लिंक काम करता है, और फिर परीक्षण कहता है कि जब यह पृष्ठ पर आता है, तो यह "Ts & Cs" जैसा दिखता है - बस अपने आप को आश्वस्त करने के लिए पर्याप्त है कि यह सही पृष्ठ है, " बिना "एक निरंतर परीक्षण", या "परीक्षण प्रस्तुति" ... तो आप यह देख सकते हैं कि पाठ सही है, उदाहरण के लिए, विशेष फ़ॉन्ट आकार या पाठ लेआउट की जांच के बिना ...