कैसे परीक्षण (इकाई-) परीक्षण डेटा गहन पीएल/एसक्यूएल अनुप्रयोग

Question

हमारी टीम मौजूदा विशाल ओरेकल प्रणाली को विस्तारित एक चल रही परियोजना के तहत लिखे गए एक नए कोड को यूनिट-टेस्ट करने के इच्छुक है।

सिस्टम पूरी तरह से पीएल/एसक्यूएल में लिखा गया है, जिसमें हजारों टेबल, सैकड़ों संग्रहीत प्रक्रिया पैकेज हैं, ज्यादातर टेबल से डेटा प्राप्त करना और/या अन्य डेटा डालने/अपडेट करना शामिल है।

हमारा एक्सटेंशन अपवाद नहीं है। अधिकांश फ़ंक्शंस कई पारस्परिक रूप से बाध्य तालिकाओं (उन्हें वापस करने से पहले थोड़ा जोड़ा तर्क के साथ) पर एक जटिल जटिल चयन कथन से डेटा लौटाते हैं या एक जटिल डेटा संरचना से दूसरे में परिवर्तन करते हैं (किसी अन्य तरीके से जटिल)।

यूनिट-टेस्ट ऐसे कोड के लिए सबसे अच्छा तरीका क्या है?

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

परीक्षण डेटा सेट को बनाए रखना असंभव प्रतीत होता है क्योंकि साप्ताहिक आधार पर उत्पादन वातावरण में तैनात नया कोड होता है, आमतौर पर पूर्व सूचना के बिना, अक्सर डेटा संरचना बदलना (यहां एक कॉलम जोड़ें, वहां एक को हटाएं)।

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

Answer 1

पीएल/एसक्यूएल के लिए कई अलग-अलग परीक्षण उपकरण हैं। Steven Feuerstein ने उनमें से दो, utplsql और Quest Code Tester for Oracle (पूर्व में QUTE) लिखा है। मैं utplsql का एक बड़ा प्रशंसक हूं, लेकिन अब इसमें सक्रिय समर्थन समुदाय नहीं है (जो शर्म की बात है)। यह भी काफी वर्बोज़ होता है, खासकर जब परीक्षण फिक्स्चर स्थापित करने की बात आती है। इसमें शुद्ध पीएल/एसक्यूएल पैकेज होने का मुख्य आभासी है; स्रोत कोड थोड़ा गड़बड़ है लेकिन यह FOSS है।

क्यूसीटीओ एक जीयूआई के साथ आता है, जिसका अर्थ है - अन्य क्वेस्ट उत्पादों की तरह i.e. TOAD - यह केवल विंडोज़ है। यह टेस्ट डेटा पीढ़ी को बिल्कुल स्वचालित नहीं करता है, लेकिन यह इसका समर्थन करने के लिए एक इंटरफ़ेस प्रदान करता है। अन्य क्वेस्ट उत्पादों की तरह, क्यूसीटीओ को लाइसेंस प्राप्त है हालांकि एक फ्रीवेयर कॉपी है।

स्टीवन (प्रकटीकरण, वह मेरे ओरेकल नायकों में से एक है) ने सभी पीएल/एसक्यूएल परीक्षण उपकरणों की एक विशेषता तुलना लिखी है। जाहिर है, क्यूओटीसी शीर्ष पर आता है, लेकिन मुझे लगता है कि तुलना ईमानदार है। Check it out.

utplsql में परीक्षण जुड़नार पर सलाह

इकाई परीक्षण के लिए प्रबंध परीक्षण डाटा गर्दन में एक असली दर्द हो सकता है। दुर्भाग्यवश utplsql बोझ कंधे के लिए ज्यादा पेशकश नहीं करता है।तो

ज्ञात मानों के खिलाफ
• हमेशा टेस्ट: dbms_random का उपयोग कर
  • से बचें;
  • अनुक्रमों के उन स्तंभों के उपयोग को प्रतिबंधित करने का प्रयास करें जिनके मूल्य कोई फर्क नहीं पड़ता;
  • तिथियां भी मुश्किल हैं। हार्ड कोडिंग तिथियों से बचें: sysdate के साथ आबादी वाले चर का उपयोग करें। सराहना करने के लिए add_months(), last_day(), interval, trunc(sysdate, 'MM'), आदि
• अन्य उपयोगकर्ताओं से परीक्षण डाटा को अलग जानें। इसे खरोंच से बनाओ। जहां भी संभव हो विशिष्ट मूल्यों का प्रयोग करें।
• केवल उतना ही टेस्ट डेटा बनाएं जितना आपको चाहिए। वॉल्यूमेट्रिक परीक्षण एक अलग जिम्मेदारी है।
• जब परीक्षण प्रक्रियाएं डेटा बदलती हैं तो प्रत्येक इकाई परीक्षण के लिए विशिष्ट रिकॉर्ड बनाते हैं।
• इसके अलावा: किसी अन्य परीक्षण से इनपुट प्रदान करने के लिए एक परीक्षण से सफल आउटपुट पर भरोसा न करें।
• जब परीक्षण प्रक्रियाएं जो उचित रूप से यूनिट परीक्षणों के बीच डेटा साझा रिकॉर्ड के खिलाफ रिपोर्ट करती हैं।
• जब भी संभव हो, फ्रेमवर्क डेटा साझा करें (उदा। प्राथमिक कुंजी)।
• यह जानने के लिए कि कौन से परीक्षण या परीक्षण रिकॉर्ड का उपयोग करते हैं, मुफ्त टेक्स्ट फ़ील्ड्स (नाम, विवरण, टिप्पणियां) का उपयोग करें।
• काम नए रिकॉर्ड बनाने में शामिल कम से कम:
  • केवल मान जो टेस्ट स्वीट और टेबल के कमी के लिए आवश्यक हैं आवंटित;
  • जितना संभव हो सके डिफ़ॉल्ट मानों का उपयोग करें;
  • जितना संभव हो सके प्रक्रियात्मक प्रक्रिया।

अन्य बातों को ध्यान में रखना:

• एक परीक्षण स्थिरता की स्थापना एक समय लेने व्यायाम हो सकता है। यदि आपके पास बहुत अधिक डेटा है, तो स्थिर डेटा सेट अप करने की प्रक्रिया बनाने पर विचार करें जिसे प्रति सत्र एक बार चलाया जा सकता है, और ut_setup में केवल अस्थिर डेटा शामिल करें। केवल पढ़ने योग्य कार्यक्षमता का परीक्षण करते समय यह विशेष रूप से सहायक होता है।
• याद रखें कि परीक्षण डेटा बनाना अपने प्रोग्राम में एक प्रोग्रामिंग व्यायाम है, और इसलिए बग के लिए प्रवण है।
• utplsql की सभी सुविधाओं का उपयोग करें। utAssert.EqQuery, utAssert.EqQueryValue, utAssert.EqTable, utAssert.EqTabCount और utAssert.Eq_RefC_Query अस्थिर डेटा के मूल्यों को समझने के लिए सभी उपयोगी विशेषताएं हैं।
• परीक्षण परीक्षण का निदान करते समय जिस तरह से हम उम्मीद नहीं कर रहे थे, वह डेटा इस्तेमाल करने के लिए उपयोगी हो सकता है। इसलिए ut_setup की शुरुआत में परीक्षण डेटा को खोखला ut_teardown प्रक्रिया और समाशोधन करने पर विचार करें।

विरासत कोड

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

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

इस क्षेत्र में बहुत सारे विचार हैं, लेकिन (अनिवार्य रूप से शर्मनाक रूप से) यह मुख्य रूप से ओओ प्रोग्रामर से आता है। माइकल फेदर्स मुख्य चैप है। अपना लेख Working Effectively With Legacy Code पढ़ें। यदि आपको यह उपयोगी लगता है तो उसने बाद में उसी नाम की एक पुस्तक लिखी।

Answer 2

utPLSQL मदद कर सकता है, लेकिन ऐसा लगता है कि आपको परीक्षण डेटा को बनाए रखने का एक बेहतर तरीका चाहिए। आप इसके लिए Swingbench भी देखना चाहेंगे।

Answer 3

मैंने यूनिट-टेस्ट पीएल/एसक्यूएल कोड में DbFit का उपयोग किया है। कोशिश करो।

Answer 4

इस परिदृश्य पर

FUNCTION ret_count (local_client_id IN number) RETURN NUMBER IS 
    v_ret number; 
BEGIN 
    SELECT count(*) INTO v_ret FROM table_1 WHERE client_id = local_client_id; 
    RETURN v_ret; 
END; 

बहुत ही सरल समारोह ले लो लेकिन वहाँ सामान की एक पूरी गड़बड़ गलत हो सकता है। डेटाटाइप रूपांतरण, अनुक्रमण, आंकड़े सभी क्वेरी पथ, प्रदर्शन और कुछ मामलों में त्रुटियों को प्रभावित कर सकते हैं। सत्र सेटिंग्स (जैसे भाषाई वरीयताओं) जैसे बहुत सारे ढीले युग्मन भी हैं। अगर कोई साथ आया और तालिका_1 में "LOCAL_CLIENT_ID" कॉलम जोड़ा, तो फ़ंक्शन का पूरा तर्क बदल जाता है।

मुझे व्यक्तिगत रूप से यह नहीं लगता कि टीडीडी इस माहौल के लिए उपयुक्त है। जानकार व्यक्तियों द्वारा कोड समीक्षा में समस्याओं को पकड़ने का एक बड़ा मौका होगा।

यदि आपके पास पैसा है, तो रिग्रेशन परीक्षण के लिए ओरेकल के आरएटी (वास्तविक अनुप्रयोग परीक्षण) को देखें।