परीक्षणों में निर्भरता इंजेक्शन

Question

आमतौर पर निर्भरता इंजेक्शन का उपयोग करते समय, इकाई (और अन्य) परीक्षण सिस्टम-अंडर-टेस्ट की निर्भरताओं को बनाने/मजाक करने और उन्हें इंजेक्शन देने के लिए ज़िम्मेदार होते हैं।

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

तो, आप इन सेटिंग्स को खोजने के लिए एक परीक्षण की सिफारिश कैसे करेंगे? क्या कुछ xUnit-style test frameworks परीक्षण फ़िक्स्चर पर निर्भरता देने का एक तरीका प्रदान करते हैं? क्या टेस्ट क्लास में सभी परीक्षण चलाने से पहले आप स्थिर गुणों को पॉप्युलेट कर सकते हैं? क्या परीक्षण डी प्रथाओं को अनदेखा कर सकता है और बस कुछ वैश्विक जगहों पर निर्भरता प्राप्त कर सकता है? अन्य सुझाव?

Answer 1

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

आपके पास एकीकरण परीक्षण हैं जो उच्च-संचालित इकाई परीक्षण ढांचे का लाभ उठाते हैं।

चूंकि वे एकीकरण परीक्षण हैं, वे यूनिट परीक्षणों से अलग हैं। "स्टैंड-अलोन-नेस" वास्तव में अब गिनती नहीं है।

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

Answer 2

पूरी तरह से स्वचालित परीक्षण के लिए एक सिद्धांत है: आप स्रोत नियंत्रण भंडार से सभी स्रोत कोड को खींचने और बस परीक्षण चलाने में सक्षम होना चाहिए।

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

इसका मतलब है कि डेटाबेस के लिए, परीक्षण

1. डेटाबेस प्रश्न में बनाना चाहिए
2. अपने परीक्षण
3. अंतिम परीक्षण मामले

हैं के बाद फिर से डेटाबेस को हटाने चलाने के लिए, किसी कारण से आप ऐसा नहीं कर सकते हैं, केवल एक चीज जो आप वास्तव में कर सकते हैं वह है कि आपके स्रोत नियंत्रण प्रणाली में कॉन्फ़िगरेशन फ़ाइल हो जिसमें आपके परीक्षण में सभी मशीनों के लिए मशीन-विशिष्ट प्रविष्टियां हों invironment; जैसे मशीन Tst1 कनेक्शन स्ट्रिंग एक मान है, लेकिन Tst2 यह एक और है।

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

यह वास्तव में डि कोई लेना देना नहीं है ...

Answer 3

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

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

आप देखते हैं, आपको यहां सावधान रहना होगा।जब भी आप एक बड़ा, जटिल परीक्षण करते हैं:

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

आदि ...