वहाँ पीएल/एसक्यूएल के लिए कई अलग-अलग परीक्षण उपकरण हैं। स्टीवन फ्यूएरस्टीन उनमें से दो को लिखा है, utplsql और Oracle के लिए क्वेस्ट कोड टेस्टर (पूर्व में QUTE)। मैं utplsql का बहुत बड़ा प्रशंसक हूं, लेकिन अब इसका सक्रिय समर्थन समुदाय नहीं है (जो शर्म की बात है)। यह काफी क्रियात्मक भी होता है, खासकर जब परीक्षण जुड़नार स्थापित करने की बात आती है। इसमें शुद्ध PL/SQL पैकेज होने का कार्डिनल वर्चुअल है; स्रोत कोड थोड़ा गड़बड़ है लेकिन यह FOSS है।
क्यूसीटीओ एक जीयूआई के साथ आता है, जिसका अर्थ है - अन्य क्वेस्ट उत्पादों की तरह यानी टॉड - यह केवल विंडोज़ है। यह परीक्षण डेटा पीढ़ी को बिल्कुल स्वचालित नहीं करता है, लेकिन यह इसका समर्थन करने के लिए एक इंटरफ़ेस प्रदान करता है। अन्य क्वेस्ट उत्पादों की तरह, क्यूसीटीओ को लाइसेंस प्राप्त है, हालांकि एक फ्रीवेयर प्रति है।
स्टीवन (प्रकटीकरण, वह मेरे ओरेकल नायकों में से एक है) ने सभी पीएल/एसक्यूएल परीक्षण उपकरणों की एक विशेषता तुलना लिखी है। जाहिर है, क्यूओटीसी सबसे ऊपर आता है, लेकिन मुझे लगता है कि तुलना ईमानदार है। इसे देखें।
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_teardownहोने पर विचार करेंut_setup. के प्रारंभ में परीक्षण डेटा की प्रक्रिया और समाशोधन ।
विरासत कोड से निपटना
गैरी की पोस्ट पर टिप्पणी करते हुए मुझे एक और बात याद आई जो आपको उपयोगी लग सकती है। स्टीवन एफ ने ulplsql को JUnit के PL/SQL कार्यान्वयन के रूप में लिखा, जो टेस्ट फर्स्ट मूवमेंट का जावा मोहरा है। हालांकि, टीडीडी की तकनीकों को बड़ी मात्रा में विरासत कोड पर भी लागू किया जा सकता है (इस संदर्भ में, विरासत कोड बिना किसी इकाई परीक्षण के कार्यक्रमों का कोई भी सेट है)।
ध्यान में रखने वाली महत्वपूर्ण बात यह है कि आपको यूनिट परीक्षण के तहत तुरंत सब कुछ प्राप्त करने की आवश्यकता नहीं है। धीरे-धीरे शुरू करें। नई सामग्री के लिए इकाई परीक्षण बनाएं, पहले परीक्षण करें . परिवर्तन लागू करने से पहले आप जिन बिट्स को बदलने जा रहे हैं, उनके लिए यूनिट परीक्षण बनाएं, ताकि आप जान सकें कि आपके द्वारा परिवर्तन किए जाने के बाद भी वे काम करते हैं।
इस क्षेत्र में बहुत सारे विचार हैं, लेकिन (अनिवार्य रूप से शर्मनाक होने पर) यह मुख्य रूप से ओओ प्रोग्रामर से आता है। माइकल फेदर्स मुख्य चैप है। उनका लेख पढ़ें लीगेसी कोड के साथ प्रभावी ढंग से काम करना . अगर आपको यह मददगार लगता है तो उन्होंने बाद में इसी नाम की एक किताब लिखी।
