यूनिट परीक्षण तृतीय पक्ष ORM

Question

मैंने यूनिट-परीक्षण विभिन्न अनुप्रयोगों की उपयोगिता के बारे में SO पर कुछ धागे पढ़े हैं। राय "यूनिट टेस्ट बेकार" के लिए "हर समय परीक्षण सब कुछ" से हो सकती हैं, और बीच में सबकुछ ("जहां यह समझ में आता है")। मैं बीच की तरफ झुकता हूं।

जो मुझे मेरे प्रश्न पर ले जाता है। link text

कुछ आधारभूत परीक्षण भविष्य को तोड़ने के परिवर्तन के खिलाफ बीमा के रूप में उपयोगी हो सकता है: मैं के रूप में इस अतः पोस्ट में सुझाव दिया तय करने के लिए करता है, तो यह फायदेमंद या व्यावहारिक कुछ बुनियादी इकाई परीक्षण परीक्षण 3 पार्टी ORM के लिए किया जाएगा कोशिश कर रहा हूँ , आप इस उपकरण का उपयोग कैसे कर रहे हैं इस पर निर्भर करता है। उदाहरण के लिए, संपूर्ण एन-स्तरीय श्रृंखला का मज़ाक उड़ाते हुए (मैं जरूरी होने पर मजाक करने का प्रशंसक नहीं हूं), केवल एक सामान्य ऑब्जेक्ट/रिकॉर्ड बनाने, पढ़ने, अपडेट करने और हटाने के लिए ORM टूल का उपयोग करें, और (परीक्षण) डेटाबेस पर प्रत्यक्ष SQL कथन का उपयोग कर ऑपरेशन को सत्यापित करें। इस तरह यदि तृतीय-पक्ष विक्रेता बाद में कुछ ऐसी चीज अपडेट करता है जो मूल कार्यक्षमता को तोड़ देता है, तो आप इसके बारे में जानेंगे, और आपके प्रोजेक्ट के नए डेवलपर आसानी से देख सकते हैं कि इकाई परीक्षण उदाहरणों से ओआरएम टूल का उपयोग कैसे करें।

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

1. ORM हम प्रयोग कर रहे स्थिर डेटा स्रोत वस्तु (रों) बनाया है और अपने डेटा एक्सेस परत साथ पंजीकृत है और प्रमाणीकृत उपयोगकर्ता के साथ जुड़े होने की आवश्यकता है। इसके लिए बहुत सारे परीक्षण सेटअप की आवश्यकता होगी, और शायद बिल्ड सर्वर पर समस्याग्रस्त हो जाएगा जहां कोई उपयोगकर्ता लॉग ऑन नहीं है।
2. ओआरएम विक्रेता के पास नए अपडेट जारी करने और बुनियादी कार्यक्षमता को तोड़ने का एक अच्छा अच्छा ट्रैक रिकॉर्ड है। इसके अलावा जब भी नवीनतम संस्करण में ओआरएम अपडेट करने का समय होता है, तो मुझे लगता है कि एप्लिकेशन सीधे उत्पादन में नहीं जायेगा, लेकिन वैसे भी पूरी तरह से रिग्रेशन परीक्षण किया जाएगा।
3. यूनिट परीक्षण के लिए परीक्षण डीबी बनाए रखना इस माहौल में समस्याग्रस्त है। टेस्ट डीबी प्रत्येक प्रमुख रिलीज के बाद मिटा दिया जाता है और डीबी बैकअप के साथ प्रतिस्थापन डेटा के साथ स्टेजिंग से बदल दिया जाता है। मैं ओआरएम इकाई परीक्षण के लिए एक परीक्षण डीबी रखने के लिए कल्पना करूंगा, हमें कुछ स्क्रिप्ट/कोड चलाने की आवश्यकता होगी जो डेटाबेस को "परीक्षण" स्थिति में सेट करेगा। फिर से बहुत अधिक सेटअप और रखरखाव।
4. और अंततः ओआरएम दस्तावेज/नए डेवलपर्स के लिए सहायता। मैं देख सकता हूं कि ऐसा कुछ कैसे उपयोगी हो सकता है। लेकिन ओआरएम विक्रेता डेमो ऐप्स के साथ बहुत अच्छी प्रलेखन/सहायता प्रदान करता है। तो इसके ऊपर यूनिट परीक्षण लिखना सभी प्रयासों के लायक नहीं लगता है।

तो, क्या यह सुनिश्चित करने के लिए कि इन ओआरएम क्या करना चाहते हैं (सीआरयूडी है) इन सभी परेशानियों से गुजरना उचित है? वैसे भी विक्रेता की ज़िम्मेदारी नहीं होनी चाहिए?

Answer 1

आपने इसे स्वयं कहा था। परीक्षण जहां यह समझ में आता है। यदि यह आपको तृतीय पक्ष ओआरएम का परीक्षण करने के लिए बेहतर महसूस करेगा, तो इसे करें। लेकिन, आखिरकार, आप अपने उपकरण में अपना विश्वास डाल रहे हैं। यदि ओआरएम अचानक काम करना बंद कर देता है तो आप क्या करने जा रहे हैं? क्या आपने इसके खिलाफ पर्याप्त कोड लिखा है कि आप आसानी से इसे बाहर नहीं निकाल सकते हैं? आप शायद इसे ठीक करने के लिए इंतजार करेंगे, शायद।

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

Answer 2

इस विशेष मामले में, मुझे परेशान नहीं होगा। मुझे लगता है कि आप यहां एक खराब आरओआई मानने में सही हैं।

और हाँ, मैं इसे विक्रेता की ज़िम्मेदारी मानता हूं। मैं उनकी सामग्री काम करता हूं (और मानता हूं)। इस तरह मैं अपने विक्रेताओं का इलाज करता हूं।

Answer 3

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

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

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

Answer 4

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

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

Answer 5

परीक्षण करना कि तीसरी पार्टी ओआरएम लाइब्रेरी का काम यूनिट परीक्षण नहीं है। हालांकि, यह आपके प्रश्न का मुद्दा नहीं है।

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

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

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

अपने आवेदन स्तर के लिए वास्तविक इकाई-स्तर परीक्षण लिखते समय, आप ओआरएम लाइब्रेरी के ऊपर रैपर का नकल करते हैं, जिसे आप करने में सक्षम हैं क्योंकि आप रैपर के कोड को नियंत्रित करते हैं।

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

"बहुत अधिक रखरखाव बोझ" स्वचालन की कमी के कारण बनाई गई एक झूठ है।