आप कैसे (यूनिट) डेटाबेस स्कीमा का परीक्षण करते हैं?

Question

जब किसी प्रोजेक्ट पर काम करने वाले बहुत से लोग हैं, जो सभी डेटाबेस स्कीमा को बदल सकते हैं, यूनिट टेस्ट/टेस्ट/सत्यापित करने का सबसे आसान तरीका क्या है? मुख्य सुझाव जो हमने अभी तक किया है, कॉलम नाम, बाधाओं आदि को सत्यापित करने के लिए प्रत्येक तालिका के लिए परीक्षण लिखना है

क्या किसी और ने कुछ भी समान/सरल किया है? हम SQL सर्वर के साथ सी # का उपयोग कर रहे हैं, अगर इससे कोई वास्तविक अंतर होता है।

अपडेट:

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

Answer 1

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

वैकल्पिक रूप से आप SQLCompare जैसे टूल का उपयोग कर सकते हैं यह देखने के लिए कि किसी डेटाबेस की तुलना में किसी डेटाबेस में क्या संशोधित किया गया है।

Answer 2

यह एक दिलचस्प सवाल है! संग्रहीत प्रक्रियाओं का परीक्षण करने के लिए वहां बहुत सारे टूल हैं लेकिन डेटाबेस स्कीमा का परीक्षण करने के लिए नहीं।

क्या आपको नहीं लगता कि कोड के लिए लिखे गए यूनिट परीक्षणों को आमतौर पर डेटाबेस स्कीमा के साथ कोई समस्या मिलती है?

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

और किसी को डीबीए होने के लिए नामांकित करें जो स्कीमा में परिवर्तनों पर नज़र रखता है?

Answer 3

आपका (रिलेशनल) डेटाबेस दो चीजें करता है जहां तक ​​मेरा संबंध है: 1) डेटा रखें और 2) डेटा के बीच संबंध रखें।

होल्डिंग डेटा एक व्यवहार है ताकि आप इसे

और संबंधों सुनिश्चित बस की कमी का उपयोग के लिए परीक्षण नहीं होता नहीं है। बहुत सारी बाधाएं सभी जगह।

Answer 4

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

Answer 5

क्या आपको नहीं लगता कि कोड के लिए लिखे गए यूनिट परीक्षणों को आमतौर पर डेटाबेस स्कीमा के साथ कोई समस्या मिलती है?

यह मानता है कि आपके परीक्षण सब कुछ परीक्षण करते हैं।

Answer 6

मुझे पहले इस तरह की चीज करना पड़ा, हालांकि सी # में नहीं।आरंभ करने के लिए, मैंने Ode to Code (page 1 of 5) पर चर्चा के आधार पर एक स्कीमा माइग्रेशन टूल बनाया (इसी तरह की चीजें करने के लिए मौजूदा टूल भी हैं)। महत्वपूर्ण बात यह है कि मैंने बनाया माइग्रेशन टूल आपको उस डेटाबेस को निर्दिष्ट करने की अनुमति देता है जिसमें आप परिवर्तन लागू कर रहे थे और आप किस संस्करण को लागू करना चाहते थे। फिर, एक परीक्षण पहली पद्धति के बाद, जब भी मुझे एक स्कीमा परिवर्तन करने की आवश्यकता होती है, तो मैं एक टेस्ट स्क्रिप्ट लिखूंगा जो एक परीक्षण डेटाबेस बनाएगा, मेरे लक्ष्य परिवर्तन स्क्रिप्ट से पहले संस्करण में परिवर्तनों को लागू करेगा, कुछ डेटा जोड़ें, परिवर्तन स्क्रिप्ट को लागू करें परीक्षण करें, और पुष्टि करें कि डेटा अपेक्षित स्थिति में था।

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

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