2010-02-22 12 views
8

क्या डाटा एक्सेस लेयर के लिए इकाई परीक्षण लिखने के लिए कोई ढांचा है? इसमें कई मुद्दे हैं।
1. अपने डेटाबेस को कैसे पॉप्युलेट करें?
2. हम कैसे सुनिश्चित करते हैं कि एक परीक्षण डीबी में मानों को संशोधित नहीं कर रहा है जो एक और परीक्षण विफल कर सकता है?नेट एक्सेस में डेटा एक्सेस लेयर के लिए टेस्ट कैसे लिखें?

क्या कोई अच्छा ढांचा उपलब्ध है जो उपर्युक्त मुद्दों का ख्याल रख सकता है?

अद्यतन: मैं एनडीबीयूनीट में आया जो डाटा एक्सेस लेयर परीक्षण के साथ बुनियादी सुविधाओं के मुद्दों का ख्याल रख सकता है।

http://code.google.com/p/ndbunit/wiki/QuickStartGuide

उत्तर

16

मुझे लगता है कि मैं इसमें शामिल रहूंगा, क्योंकि मैं अब तक कुछ जवाबों को वास्तव में नापसंद करता हूं।

चाहे आप इसे "यूनिट टेस्ट" या "एकीकरण परीक्षण" या "supercalifragilisticexpialidocious test" कहते हैं, इस उदाहरण में कोई फर्क नहीं पड़ता; डेटा एक्सेस घटकों के लिए केवल एक वैध परीक्षण है और यह वास्तविक डेटा पर परीक्षण करना है। उत्पादन डेटा स्पष्ट रूप से नहीं है, लेकिन इसकी एक उचित प्रतिकृति है।

आपको सबसे पहले जो करना है वह get the database itself under source control है। अफसोस की बात है, इसके लिए कोई ढांचा नहीं है; माइक्रोसॉफ्ट वीएसटीएस के कुछ संस्करणों में रास्ता तय करता है लेकिन अंतिम परिणाम अभी भी कुछ हद तक कम है। कम से कम आज की दुनिया में, आपको अपने आप को बहुत सारे काम करना होगा। लेकिन इसे गंभीरता से करें - जब आपको एक बड़ा अपडेट बॉट हो जाता है तो आपको खेद नहीं होगा और आपको डीबी वापस रोल करने की आवश्यकता है।

जो आपने सोर्स कंट्रोल के तहत रखा है, वह नवीनतम स्कीमा, आमतौर पर बेसलाइन स्क्रिप्ट, साथ ही "कॉन्फ़िगरेशन डेटा" स्क्रिप्ट्स (यानी गणना तालिकाओं की सामग्री) उत्पन्न करने के लिए आवश्यक है, और हालिया स्कीमा परिवर्तनों को दर्शाने के लिए स्क्रिप्ट को अपग्रेड करना आवश्यक है। यह आपको लगभग देता है जो आपको अस्थायी डेटाबेस पर "लाइव" परीक्षण करने की आवश्यकता होती है; आपके परीक्षण को केवल उन स्क्रिप्ट को स्रोत नियंत्रण से डाउनलोड करने की आवश्यकता होती है और उन्हें एक परीक्षण सर्वर और/या एक अलग डेटाबेस उदाहरण पर चलाया जाता है, आमतौर पर SQL Management Objects का उपयोग स्क्रिप्ट चलाने के लिए करते हैं (एसएमओ GO कथन संभाल सकता है और जैसा; नियमित SqlConnection नहीं कर सकता)।

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

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

+0

इस पूरी तरह से सहमत है। – kyoryu

+0

मैंने परीक्षण डेक के लिए माइक्रोसॉफ्ट के एसक्यूएल सर्वर एक्सप्रेस का उपयोग किया है; हम .mdf फ़ाइलों को स्रोत नियंत्रण में जांचते हैं। (एसक्यूएल सर्वर फ्लाई पर .ldf फ़ाइलों को फिर से बनाएगा।) यह मजेदार नहीं है, और आप आरएनयूयू और यूजर इंस्टेंस के बारे में सीखने के तरीके को और अधिक सीखना चाहते हैं। लेकिन यह काम करता है। – TrueWill

+0

@ ट्राउविल: हार्ड कोर, उम्मीद है कि उन परीक्षण डेटाबेस छोटे हैं, अन्यथा एससी सर्वर पर बहुत सी डिस्क स्पेस चबाएंगे! यह निश्चित रूप से एक विकल्प है कि यह आपके बुनियादी ढांचे के साथ फिट बैठता है - हमारे लिए, भले ही हमने 1.5 जीबी डाटाबेस को परीक्षण के लिए 1.5 जीबी तक रखा हो, फिर भी यह स्रोत में जांच करने के लिए थोड़ा हास्यास्पद होगा। ;) – Aaronaught

3

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

+7

इस से असहमत होना है। इकाई परीक्षण डेटा किसी भी चीज के खिलाफ कक्षाओं का उपयोग करता है जो * वास्तविक डेटाबेस नहीं है, केवल खाली अनुष्ठान है। एक "सत्य" इकाई परीक्षण डेटाबेस निर्माण/अपग्रेड स्क्रिप्ट का उपयोग करेगा जो आप निश्चित रूप से संस्करण नियंत्रण के अंतर्गत रखते हैं, परीक्षणों के लिए एक सैंडबॉक्स डेटाबेस बनाते हैं, और अंत में इसे नीचे फाड़ते हैं। – Aaronaught

+0

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

+1

@ user210118: यदि डेटा एक्सेस कोड आंतरिक रूप से एसपी कहता है और प्रदर्शन कारणों से एसपी में कुछ कोड लिखा गया है तो क्या होगा। मैं यह जांचना चाहता हूं कि क्या एसपी ऐसा कर रहा है जो इसे करना है। – Amitabh

3

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

+0

लेकिन यह अभी भी प्रारंभिक डेटा आबादी के मुद्दे को हल नहीं करेगा। मैं एक ढांचे की तलाश में हूं जो इन चीजों को आसान बना सकता है ताकि टीम में हर कोई टेस्ट टेस्ट पर ध्यान केंद्रित कर सके। – Amitabh

+0

आपका परीक्षण डेटाबेस कभी शुरू नहीं किया जाना चाहिए! यह एक खाली डेटाबेस होना चाहिए जिसमें कुछ भी नहीं है। क्या आप आरंभिक डेटा आबादी पर विस्तार कर सकते हैं? – azamsharp

+2

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

1

मत करो। यूनिट परीक्षण डीबी तक नहीं पहुंचते हैं। यही एकीकरण या कार्यात्मक परीक्षण के लिए हैं।

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

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

+0

क्या होगा यदि _I_ चिंता करें कि मेरे यूनिट परीक्षण कितने तेज़ हैं, और आप नहीं करते? –

+10

यदि परीक्षण वास्तव में किसी भी डेटा तक नहीं पहुंचता है तो यूनिट-परीक्षण * डेटा एक्सेस * कक्षा कितनी अच्छी है? यदि हम परिभाषाओं पर झुकाव कर रहे हैं तो ठीक है, अपने डीएएल को "यूनिट टेस्ट" न करें, "एकीकरण परीक्षण"। शुद्ध परिणाम एक ही बात है। एकमात्र चीज जो * समझ में नहीं आता है, निम्न स्तर के डीएएल परीक्षणों के लिए डेटाबेस का मज़ाक उड़ा रहा है; यह बेकार से भी बदतर है, यह आपको हरा प्रकाश दिखाता है जब कक्षा वास्तव में पूरी तरह टूटा जा सकता है। – Aaronaught

+0

@ हारून: पूरी तरह से सहमत हुए। मैं 'जो आपके पास नहीं है उसका मज़ाक उड़ाओ' का एक बड़ा समर्थक हूं। यदि इकाई परीक्षण अपेक्षित व्यवहार को परिभाषित करता है, तो उस कोड के व्यवहार को परिभाषित करना मुश्किल है जिसका आपके पास स्वामित्व नहीं है। – kyoryu

संबंधित मुद्दे