आप अपने टी-एसक्यूएल का परीक्षण कैसे करते हैं? आप किस पुस्तकालय/उपकरण का उपयोग करते हैं?
इस TSQLUnit और यह tSQLt पर एक नज़र डालें।
मैंने टी-एसक्यूएल, ऐसे जूनिट या नूनिट का परीक्षण करने के लिए कई भाषाओं में कुछ अलग-अलग ढांचे का उपयोग करने के साथ प्रयोग किया है। इस मार्ग पर जाने का कारण यह था कि इन अन्य भाषाओं में समृद्ध परीक्षण वातावरण का लाभ उठाएं। उदाहरण के लिए यदि आप नूनिट का उपयोग करते हैं तो इसमें आपके परीक्षण की स्थिति को देखने के लिए एक अच्छी कमांड लाइन और गुई व्यूअर है और क्योंकि आपके परीक्षणों को लिखने के लिए .net का उपयोग करके यह एसक्यूएल सर्वर में बहुत आसानी से हुक करता है। जुनीट के पास बहुत सारे वाणिज्यिक और ओपन सोर्स आईडीई वातावरण जैसे नेटबीन और आईडीईए के साथ कुछ अच्छा एकीकरण है, साथ ही टी-एसक्यूएल परीक्षण जावा कोड परीक्षण की तरह अधिक है, जो बहुत समृद्ध है। नकारात्मक यह है कि आप केवल टी-एसक्यूएल नहीं लिख रहे हैं, आप अपने टी-एसक्यूएल का परीक्षण करने के लिए जावा या नेट लिख रहे हैं।
मैंने रूबी के साथ रूबी का उपयोग भी किया है (यह मेक या चींटी की तरह है) और एसक्यूएलएमएमडी को एसक्यूएलसीएमडी को निष्पादित एसक्यूएल स्क्रिप्ट्स में कॉल किया गया है जो बदले गए परीक्षणों में है। स्क्रिप्ट्स मूल्यों को वापस लौटते हैं और परीक्षण को विफल या विफल करने के लिए रूबी पर वापस आते हैं। मुझे इस दृष्टिकोण को सबसे अच्छा लगा क्योंकि यह बहुत दुबला और दूसरों के लिए चुनना आसान था। उपरोक्त वर्णित अन्य मार्गों में डेवलपर्स को .NET या जावा का उपयोग करने की आवश्यकता होती है, यदि आपके पास सभी डीबीए प्रकारों को दूर करना मुश्किल हो सकता है, जहां एसक्यूएल स्क्रिप्ट दृष्टिकोण के साथ रूबी मेरे अनुभव से बेचना आसान है। डीबीए प्रकार खुले होते हैं और भाषाओं की तरह स्क्रिप्टिंग चुनने में सक्षम होते हैं और रूबी के पास कम सीखने की वक्र होती है और स्क्रिप्ट एक .net या जावा क्लास के सापेक्ष चलाने के लिए आसान होती हैं।
आपके कोड का प्रतिशत प्रतिशत यूनिट परीक्षणों द्वारा कवर किया गया है और आप इसे कैसे मापते हैं?
शायद केवल 20% ही क्योंकि अधिकांश डेटाबेस सिस्टमों ने ऐतिहासिक रूप से उनके लिए बनाए गए परीक्षणों के रूप में परीक्षण नहीं किए हैं, इसलिए मैं रेट्रो सक्रिय रूप से परीक्षण जोड़ रहा हूं और नए दोषों और संवर्द्धन के रूप में परीक्षण जोड़ रहा हूं।
क्या आपको लगता है कि आपने अपने यूनिट परीक्षण दोहन में निवेश किए गए समय और प्रयास का भुगतान किया है या नहीं?
डेटाबेस अधिकांश व्यवसायों की रोटी और मक्खन है। यह हमेशा मेरी राय में भुगतान करता है। यदि आपका व्यवसाय ग्राहक के लिए जंक और उच्च विफलता दर को सहन करता है तो कोई परीक्षण संभवतः इसके लायक नहीं है क्योंकि यह करने के लिए स्वतंत्र नहीं है।
यदि आप यूनिट परीक्षण का उपयोग नहीं करते हैं, तो क्या आप समझा सकते हैं क्यों नहीं?
मुझे यह देखना अच्छा लगेगा कि कोई इसके लिए उत्तर के साथ आता है जो बेतुका नहीं है। किंडा की तरह आप सड़क पर गाड़ी चलाते समय अपने बच्चे को कार सीट में क्यों नहीं डालते ... "उन्हें बहुत अधिक खर्च होता है" ... "इसमें बच्चे को रखने के लिए बहुत अधिक समय लगता है" .. "वह इसके बिना सुरक्षित है ".." इसे उचित ठहराने में क्या गलत हो सकता है ".." बस पर्याप्त समय नहीं है "ये सभी बीएस हैं।
हाँ, मुझे थोड़ा चरम पता है, लेकिन वास्तव में यदि आपके पास सिस्टम है और यह कंपनी के मूल्य को लाता है तो इसे उत्पादन के मुद्दों से पहले कुछ मुद्दों को पकड़ने में मदद के लिए एकजुट परीक्षण किया जाना चाहिए। यूनिट परीक्षण एक पैनसिया नहीं है, लेकिन यह एक ऐसा टूल है जिसे हमें सबसे अच्छा करना है।
मैं कहूंगा कि किसी भी तरह से अधिकांश लोग डेटाबेस को एक नि: शुल्क पास देते हैं जब यह संरचित परीक्षण की बात आती है। मुझे नहीं पता कि यह क्यों है, लेकिन मैंने इसे कंपनी के बाद कंपनी में देखा है। मुझे वह बदलाव देखना अच्छा लगेगा।
स्टारशिप 3000, क्या आप TSQLUnit का उपयोग कर रहे हैं? क्या आप अपेक्षित मूल्यों के मुकाबले पूरे परिणाम सेट की तुलना करते हैं, या आप व्यक्तिगत मूल्यों को अलग से मेल खाते हैं? –
वर्तमान में नहीं, मैं अतीत में TSQLUnit का उपयोग नहीं कर रहा हूं। अब मैं रुबी से एक यूनिट परीक्षण ढांचे का उपयोग करता हूं और रुबी ने मेरी एसक्यूएल स्क्रिप्ट निष्पादित की है जिसमें एसक्यूएलसीएमडी के लिए कॉल के माध्यम से 1 टेस्ट होता है। यह कॉल तब रूबी को पास असफल मान और स्ट्रिंग विवरण देता है। जब मेरे पास कुछ समय होगा तो मैं सरल उदाहरण खोदूंगा। – Kuberchaun