unit testing - यूनिट टेस्ट बनाम स्वीकृति टेस्ट




unit-testing tdd (4)

क्या आप एक या दूसरे के लिए हैं? अथवा दोनों?

मेरी समझ यूनिट परीक्षण है:

  • डेवलपर के दृष्टिकोण से सिस्टम को मान्य करें
  • डेवलपर्स टीडीडी का अभ्यास करने में मदद करें
  • कोड मॉड्यूलर रखें
  • ग्रैन्युलरिटी के निम्न स्तर पर त्रुटियों का पता लगाने में सहायता करें

स्वीकृति परीक्षण:

  • व्यापार से सिस्टम और क्यूसी / क्यूए अंक के दृष्टिकोण को मान्य करें
  • उच्च स्तर के रूप में होते हैं क्योंकि वे अक्सर लोगों द्वारा लिखे गए हैं जो कोड की आंतरिक कार्यप्रणाली से परिचित नहीं हैं

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

इकाई परीक्षण बनाम स्वीकृति परीक्षण, और एक-दूसरे के संबंध में उन्हें प्रबंधित करने के तरीके पर सामान्य रूप से आपके विचार क्या हैं?


हालांकि, अनावश्यक काम को कम करने के लिए, क्या यूनिट परीक्षणों को स्वीकृति परीक्षण में शामिल करने का प्रयास करना एक अच्छा विचार है?

नहीं।

दूसरे शब्दों में, बाद वाले [स्वीकृति] को पूर्व [इकाई] कहते हैं। विपरीत दिशा में जा रहा है कोई मतलब है?

भेजा मत खा।

स्वीकृति परीक्षण अक्सर राजनीतिक होते हैं। आप उन्हें उन लोगों को दिखाते हैं जो - उनके आंत वृत्ति के आधार पर - स्वीकार करने या अस्वीकार करने का निर्णय लेते हैं।

फिर आप स्वीकृति परीक्षण की वैधता के बारे में बहस करते हैं।

फिर आप काम के दायरे और अगली रिलीज के बारे में बहस करते हैं।

स्वीकृति परीक्षण नहीं हैं - आम तौर पर - तकनीकी। यदि वे थे, तो आपके पास औपचारिक इकाई परीक्षण होंगे और वह वह होगा।

राजनीति को शांत करने की कोशिश मत करो। इसे गले लगाने। इसे होने दो।

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

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

सभी टेस्ट-फर्स्ट (टीडीडी, एटीडीडी, या कुछ और) के पीछे आधार यह है कि एक परीक्षण लोहे से बने समझौते है। इसके अलावा यह नहीं है। किसी भी टीडीडी (या एटीडीडी) विधि के साथ आप सहमत हो सकते हैं - सैद्धांतिक रूप से - परीक्षा परिणामों के लिए , लेकिन आप वास्तव में परीक्षण के लिए सहमत नहीं हैं।

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

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

अधिक परीक्षण किसी और चीज़ से बेहतर है। परीक्षणों के बीच एक सबसेट-सुपरसेट संबंध को मजबूर करने की कोशिश करने से सभी परीक्षणों का संघ अधिक मूल्यवान है।


उपर्युक्त सारांश के रूप में,

  • स्वीकृति परीक्षण सुनिश्चित करते हैं कि आप सही चीज़ बना रहे हैं
  • यूनिट परीक्षण सुनिश्चित करते हैं कि आप सही चीज़ बना रहे हैं

यूनिट टेस्ट - मेरा विशिष्ट कार्य करता है जो इसे करना है, और कुछ नहीं, और कुछ भी कम नहीं है।

स्वीकृति परीक्षण - मेरा आवेदन करता है जो इसे करना है।

उदाहरण: वर्गवार कार्यों की जड़ों की गणना करने के लिए आवेदन। ए, बी, और सी के इनपुट लेता है, जड़ x1 और x2 देता है। यह एप्लिकेशन दो संख्याओं को जोड़ने के लिए लिखने वाले कार्यों द्वारा बनाया गया है, दो संख्याओं को घटाएं, दो संख्याओं को गुणा करें, दो संख्याओं को विभाजित करें, और दो संख्याओं के वर्ग रूट को लें।

यूनिट परीक्षण - जांचें कि मेरा विभाजन और गुणात्मक कार्य सही तरीके से काम करते हैं, मेरा वर्ग रूट सही तरीके से काम करता है, मेरा जोड़ और कार्य को सही तरीके से घटाता है।

स्वीकृति परीक्षण - जांचें कि मेरा आवेदन वर्गबद्ध कार्यों की जड़ों की गणना करता है।

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


स्वीकृति और एकीकरण परीक्षण आपको बताता है कि आपका कोड काम कर रहा है और पूरा हो गया है; यूनिट परीक्षण आपको बताते हैं कि यह कहां विफल रहा है।

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

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

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





acceptance-testing