क्या यूनिट आपके एसक्यूएल को टीडीडी लेने के लिए बहुत दूर परीक्षण कर रहा है?

Question

आपके एसक्यूएल परीक्षण इकाई के बारे में www.sqlservercentral.com पर एक लेख है।

मेरे अंदर टीडीडी लड़का अच्छा कहता है, हम डेटाबेस सामान का परीक्षण कर सकते हैं।

मेरे अंदर सिस्टम आर्किटेक्ट ने कहा, हम किस तर्क का परीक्षण कर रहे हैं? डेटाबेस में कोई तर्क नहीं होना चाहिए, डेटा बेस में केवल एक चीज आपको करना चाहिए, चयन करना, अपडेट करना या डालना है।

तो यदि आपको अपने एसक्यूएल का परीक्षण करने की आवश्यकता महसूस हो रही है, तो क्या आप वास्तव में पूरी तरह से पूर्ण हैं, अत्यधिक व्यावहारिक होने के नाते, या यह डिजाइन गंध का संकेत है?

Answer 1

मैं सिस्टम आर्किटेक्ट से सहमत हूं, बहुत अधिक व्यावसायिक तर्क इन दिनों डेटाबेस में अपना रास्ता बना रहा है।

Answer 2

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

Answer 3

आपके एसक्यूएल में तर्क शामिल है। उदाहरण के लिए, "WHERE" खंड में बूलियन स्थिति जांचती है। क्या आप किसी भी तरीके से सोच सकते हैं जिसमें एसक्यूएल गलत हो सकता है? यदि हां, तो यह सुनिश्चित करने के लिए कि ये त्रुटियां मौजूद नहीं हैं, एसक्यूएल का परीक्षण करना समझदारी होगी?

(उदाहरण के लिए, मेरे जैसे कुछ मूर्ख प्रोग्रामर, मेरी टिप्पणी में "कहां" के बजाय "WHILE" को गलती से टाइप कर सकते हैं ... जैसा मैंने किया था। लेकिन मैंने बाद में इसे सही किया। तो मेरे स्टैक ओवरफ्लो परीक्षण कहां हैं ?!? ;-)

Answer 4

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

Answer 5

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

लेकिन यदि आपके पास जटिल कार्य, संग्रहित प्रक्रियाएं, ट्रिगर्स इत्यादि हैं ..., तो आपके पास बहुत सारे स्थान हैं जहां बग हो सकता है और एप्लिकेशन यूनिट परीक्षण उन्हें कवर नहीं करता है।

Answer 6

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

संपादित:

उदाहरण के लिए, मैं और डालने पर एक डिफ़ॉल्ट मान एक ट्रिगर अद्यतन पर सम्मिलित/अपडेट करने पर "अंतिम अपडेट समय" फ़ील्ड सेट करनी का प्रयोग करेंगे। LINQ में मैं स्तंभ को एक स्वत: उत्पन्न मान के रूप में सेट कर दूंगा और इसे केवल पढ़ने के लिए तैयार करूंगा। यह सुनिश्चित करने के लिए कि जब भी इकाई पर कोई फ़ील्ड बदल जाता है, तो यह सुनिश्चित करने के लिए एक संपत्ति चेंज इवेंट हैंडलर जोड़ने से मेरे लिए यह आसान है, अंतिम अद्यतन समय भी बदला जाता है। क्या मैं इसका परीक्षण करता हूँ? निश्चित रूप से, लेकिन मैन्युअल रूप से और तथ्य के बाद भी मैं ज्यादातर चीजों के लिए टीडीडी को दृढ़ता से पसंद करता हूं।

Answer 7

जब तक WHERE क्लॉज खाली नहीं होता है, तो इसका परीक्षण किया जाना चाहिए।

यहां हम डेटाबेस क्वेरी करने के लिए NHibernate मानदंड API का उपयोग करते हैं। फिर भी, हम डेटा एक्सेस परत की सुरक्षा के लिए सरल यूनिट परीक्षण डालते हैं। इस पर विचार करें:

public IList<Book> GetBorrowedBooks(User user); 

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

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

Answer 8

मुझे नहीं पता कि जब हमने डीबी परत मारा तो सभी अच्छे अभ्यास को खिड़की पर जाना चाहिए। यदि इस परत में तर्क दोगुना महत्वपूर्ण है। Fitnesse के शीर्ष पर बनाया गया एक शानदार टूल है जिसे dbfit कहा जाता है जो कि डीबीएयर परीक्षण इकाई के सभी दर्द को दूर करता है। यदि आप रुचि रखते हैं तो आपको एक नज़र रखना चाहिए।

Answer 9

इकाई परीक्षण/चश्मा और एकीकरण परीक्षणों/चश्मा के बीच अलग पहचान बनाएं।

यदि आपके वर्ग दोनों में हैं तो आप एक ध्वनि सिद्धांत का उल्लंघन कर रहे हैं: Separation of Concerns।

आपके परीक्षणों को संस्थाओं, सेवाओं और एकीकरण परीक्षण जैसे निरंतर अज्ञानी पीओसीओ/पीओजेओ इकाइयों का परीक्षण करने के लिए यूनिट परीक्षणों के बीच स्पष्ट रूप से परिभाषित किया जाना चाहिए। जो परीक्षण के लिए हैं जहां आपका एप्लिकेशन धातु को हिट करता है। अपने यूज-केस पूरी तरह से परीक्षण एक आवश्यक हैं

एकता परीक्षण इस तरह के खजाने और अपने हठ तंत्र (RBDMS), सक्रिय निर्देशिका, एक्सचेंज, फाइल सिस्टम और ईमेल आदि

के लिए काम करते कार्यान्वयन की इकाई के रूप में दृढ़ता का परीक्षण करना चाहिए एकीकरण बिंदु, जो एक ट्रिगर का उपयोग करता है, तब व्यवहार का परीक्षण करें, ट्रिगर स्पष्ट रूप से नहीं। भविष्य में आप एक ट्रिगर का उपयोग नहीं करना चुन सकते हैं और इसके बजाय ओआरएम या एओपी इंटरसेप्टर का उपयोग नहीं कर सकते हैं।

Answer 10

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

• टेबल्स & विचार:: टेबल और विचारों आप अस्तित्व के लिए उम्मीद की जाँच करें

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

• बाधाएं: अस्वीकार किए जाने वाले डेटा परिवर्तनों को निष्पादित करने का प्रयास करें। बाधाओं को इन परिवर्तनों को रोकना चाहिए। यदि आप उन मामलों को पकड़ते हैं जहां बाधाएं काम नहीं कर रही हैं तो आप बाद की बग से बच सकते हैं।

• ट्रिगर्स: बाधाओं के समान, और ट्रिगर का उपयोग कैस्केडिंग प्रभावों के लिए या मूल्यों को बदलने के लिए भी किया जा सकता है। इन तर्क पथों का परीक्षण करें।

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

• बूटस्ट्रैप डेटा: लुकअप टेबल डेटा का एक उदाहरण है जिसे "खाली" डेटाबेस में भी मौजूद होना आवश्यक है। अन्य उदाहरण भी हो सकते हैं। परीक्षण करें कि डेटाबेस में आवश्यक डेटा है।

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

• ओआरएम कक्षाएं: ट्रिगर्स की तरह, आपके आवेदन में ओआरएम कक्षाएं डेटाबेस संचालन को मान्य करने, बदलने, या निगरानी करने के लिए तर्क शामिल हो सकता है। इनका परीक्षण किया जाना चाहिए।

इन परीक्षणों को सटीक रूप से "यूनिट परीक्षण" नहीं कहा जा सकता है। यूनिट परीक्षण एक विशिष्ट प्रकार का परीक्षण है जहां प्रत्येक परीक्षण अन्य परीक्षणों से स्वतंत्र होता है, और आप अलगाव में कोड की छोटी इकाइयों का परीक्षण करने का प्रयास करते हैं। मैं कहूंगा कि डेटाबेस का परीक्षण ऊपर उल्लिखित तरीके कार्यक्षमता परीक्षण का एक उदाहरण है।

Answer 11

सिस्टम आर्किटेक्ट सही है। आपके डेटाबेस में व्यावसायिक तर्क डालना नहीं चाहिए और इस प्रकार आप वास्तव में कुछ भी परीक्षण नहीं कर रहे हैं।

Answer 12

DbFit डेटाबेस परीक्षण इकाई के लिए एक अच्छा उपकरण है। मुझे लगता है कि एसक्यूएल के साथ टीडीडी का उपयोग करना बुद्धिमानी है क्योंकि, आखिरकार, यह सशर्त शाखाओं, कुल कार्यों, और आगे के साथ एक घोषणात्मक भाषा है। परीक्षण के बिना, आप कैसे सुनिश्चित कर सकते हैं कि आप इच्छित परिणाम प्राप्त कर रहे हैं?