वेब विकास में यूनिट टेस्ट बनाम एकीकरण परीक्षण

Question

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

1. अनुमान

परिभाषा यूनिट टेस्ट केवल एक सेवा परत पर कोड का परीक्षण करना चाहिए द्वारा। यदि एक परीक्षण परीक्षण कई परतों में कोड परीक्षण करता है तो हमारे पास एकीकरण परीक्षण होता है।

2. तर्क

2,1 कोई एल्गोरिदम

एक वेब अनुप्रयोग में कई नहीं एल्गोरिदम रहे हैं। यह एक 3 डी भौतिकी इंजन बनाने की तरह नहीं है जहां हर विधि कुछ चुनौतीपूर्ण और डीबग करने में मुश्किल होती है। वेब एप्लिकेशन ज्यादातर एकीकरण और HTML उत्पन्न करने के बारे में है।

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

यदि आप किसी वेब ऐप में प्रत्येक कक्षा के लिए यूनिट टेस्ट बनाना चाहते हैं तो आप परीक्षण करेंगे (ज्यादातर मामलों में): सरणी भरना , स्ट्रिंग concatenations और भाषाओं के मूल कार्यों।

2,2 लागत

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

3. एकता टेस्ट

तो वेब विकास सभी एकीकरण के बारे में यह क्यों परीक्षण करने के लिए नहीं है? कुछ काउंटर तर्क हैं।

3.1 एकता परीक्षण कहते हैं, "कुछ टूट गया है" लेकिन कहना नहीं है जहां

यह वास्तव में करने के लिए नीचे आता है: कितना समय यह जब एक एकीकरण परीक्षण समय की तुलना में विफल रहता है एक बग मिल के लिए ले करता कोड "यूनिटटेस्टेबल" बनाने के लिए आवश्यक है और अधिक जटिल (मुझे लगता है कि यह व्यक्तिपरक है)? मेरे अनुभव में किसी समस्या का स्रोत खोजने में कभी भी समय नहीं लगा।

3.2 आप किसी भी पर्यावरण पर इकाई परीक्षण चला सकते हैं, यह एक एकीकरण परीक्षण

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

3.3 एकता बनाए रखने के लिए टेस्ट

मैं सभी क्योंकि अपने परीक्षण काम अच्छी तरह से उस पर टिप्पणी नहीं कर सकता मुश्किल कर रहे हैं और मैं कभी नहीं कि साथ समस्या थी।

4. अच्छा यूनिट टेस्ट बनाएं!

पूरे तर्क पर हमला किया जा सकता है "यदि आप अपना यूनिट टेस्ट सही बनाते हैं, तो आपको कोई समस्या नहीं है।" क्या यह एकीकरण परीक्षण के साथ समान नहीं हो सकता है? यदि एकीकरण परीक्षण बनाना आसान है, तो इसके साथ क्यों न रहें और इसे सही बनाएं?

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

Answer 1

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

के अपने अंक के माध्यम से चलते हैं:

नहीं एल्गोरिदम (लेकिन क्या आपका मतलब है कुछ है):

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

लागत

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

एकता टेस्ट

टेस्ट वह भी!

एकता परीक्षण कहते हैं, "कुछ टूट गया है" लेकिन कहना नहीं है जहां

मैं माफी चाहता हूँ, लेकिन मैं इस एक समझ में नहीं आता।

हार्ड

बनाए रखने के लिए यदि यह आप गलत कर रहे बनाए रखने के लिए कठिन है। कोड को बदलते समय पहले परीक्षण लिखें, कार्यान्वयन से पहले परीक्षण बदलें। टीडीडी के लिए विकास के दौरान विफल होना जरूरी है। असल में मुझे उस पर उद्धरण न दें, यह सिर्फ टीडीडी की मेरी सीमित समझ है।

मैं this खोजने के यूनिट-परीक्षण के बारे में एक बहुत अच्छा उद्धरण

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

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

संपादित समुदाय विकी एकीकरण परीक्षण के बारे में इस का कहना है:

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

तो वास्तव में integration testing की मेरी समझ शुरुआत से गलत थी, लेकिन मुझे नहीं लगता कि मेरा उत्तर अंतिम पैराग्राफ को छोड़कर बहुत दूर है।

Answer 2

एकीकरण परीक्षण इकाई परीक्षण की तुलना में निष्पादित करने में अधिक समय लगता है।

"... सभी एकीकरण के बारे में हमेशा कई निर्भरताएं हैं" -> यदि आप दूसरों को पूरा किए बिना एक निर्भर इकाई पर कोडिंग कर रहे हैं, तो आप अभी तक एकीकरण परीक्षण नहीं कर सकते हैं। यदि आप यह सुनिश्चित करना चाहते हैं कि आपका कोड इस बिंदु पर काम कर रहा है, तो आप यूनिट परीक्षण कर सकते हैं।

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

Answer 3

यह एक लानत अच्छा सवाल है, और एक कि अधिक डेवलपर्स खुद को पूछ किया जाना चाहिए।

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

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

• यूनिट परीक्षण महत्वपूर्ण है, इकाई परीक्षण योग्य "libs" (प्रमाणीकरण, बिलिंग, सेवा संक्षेपण हैं, आदि)
• यूनिट परीक्षण मॉडल, यह सोचते हैं आप किसी भी है, जहां संभव (और यह वास्तव में संभव हो जाना चाहिए!)
• एकता परीक्षण आपके आवेदन की महत्वपूर्ण अंतिमबिंदुओं (पूरी तरह एप्लिकेशन पर निर्भर करता है)

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

यूनिट परीक्षण और एकीकरण परीक्षण परस्पर अनन्य नहीं हैं, और जब तक कि आप एक सुंदर इकाई परीक्षण योग्य पुस्तकालय नहीं बना रहे हैं, तो आपको दोनों करना चाहिए।