database - यूनिट-परीक्षण डेटाबेस-संचालित अनुप्रयोगों के लिए सबसे अच्छी रणनीति क्या है?




unit-testing orm (4)

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

लेकिन ओआरएम और डेटाबेस का परीक्षण हमेशा समस्याओं और समझौता से भरा हुआ है।

सालों से, मैंने कुछ रणनीतियों की कोशिश की है, जिनमें से कोई भी मुझे पूरी तरह से संतुष्ट नहीं करता है।

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

  • उत्पादन डेटाबेस की एक प्रति लोड करें और उसके खिलाफ परीक्षण करें। यहां समस्या यह है कि आपको पता नहीं हो सकता कि किसी भी समय उत्पादन डीबी में क्या है; समय के साथ डेटा बदलते समय आपके परीक्षणों को फिर से लिखना पड़ सकता है।

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

  • एक नकली डेटाबेस सर्वर का उपयोग करें, और केवल जांच करें कि ओआरएम किसी दिए गए विधि कॉल के जवाब में सही प्रश्न भेज रहा है।

डेटाबेस-संचालित अनुप्रयोगों का परीक्षण करने के लिए आपने किन रणनीतियों का उपयोग किया है, यदि कोई है? आपके लिए सबसे अच्छा क्या काम करता है?


जेडीबीसी आधारित परियोजना के लिए (सीधे या परोक्ष रूप से, जैसे जेपीए, ईजेबी, ...) आप पूरे डेटाबेस को नकल नहीं कर सकते हैं (ऐसे मामले में वास्तविक आरडीबीएमएस पर एक परीक्षण डीबी का उपयोग करना बेहतर होगा), लेकिन केवल जेडीबीसी स्तर पर नकली ।

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

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

Acolyte ढांचे में इस तरह के नकली के लिए एक जेडीबीसी चालक और उपयोगिता शामिल है: http://acolyte.eu.org


मैं इन कारणों से हमेशा इन-मेमोरी डीबी (एचएसक्यूएलडीबी या डर्बी) के खिलाफ परीक्षण चला रहा हूं:

  • यह आपको लगता है कि आपके परीक्षण डीबी में क्यों डेटा रखना है और क्यों। बस एक परीक्षण प्रणाली में अपने उत्पादन डीबी को घुमाने के लिए अनुवाद करता है "मुझे नहीं पता कि मैं क्या कर रहा हूं या क्यों और अगर कुछ तोड़ता है, तो यह मैं नहीं था !!" ;)
  • यह सुनिश्चित करता है कि डेटाबेस को एक नए स्थान पर कम प्रयास के साथ पुनर्निर्मित किया जा सकता है (उदाहरण के लिए जब हमें उत्पादन से बग को दोहराने की आवश्यकता होती है)
  • यह डीडीएल फाइलों की गुणवत्ता के साथ काफी मदद करता है।

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

डेटा एसक्यूएल, एक टेम्पलेट डीबी या डंप / बैकअप से भरा हुआ है। अगर वे एक पठनीय प्रारूप में हैं तो मैं डंप पसंद करता हूं क्योंकि मैं उन्हें वीसीएस में डाल सकता हूं। अगर यह काम नहीं करता है, तो मैं एक सीएसवी फ़ाइल या एक्सएमएल का उपयोग करता हूं। अगर मुझे भारी मात्रा में डेटा लोड करना है ... मैं नहीं करता हूं। आपको डेटा की भारी मात्रा में लोड नहीं करना पड़ेगा :) यूनिट परीक्षणों के लिए नहीं। प्रदर्शन परीक्षण एक और मुद्दा हैं और विभिन्न नियम लागू होते हैं।


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

मैं पहले अपने परीक्षण पर्यावरण के खिलाफ सभी परिवर्तन (डेटाबेस स्कीमा सहित) भी करता हूं, इसलिए यह दूसरे तरीके से समाप्त होता है: सभी परीक्षण पास होने के बाद, उत्पादन होस्ट को स्कीमा अपडेट लागू करें। मैं अपने विकास प्रणाली पर परीक्षण बनाम एप्लिकेशन डेटाबेस की एक अलग जोड़ी भी रखता हूं ताकि मैं वहां सत्यापित कर सकूं कि डीबी अपग्रेड वास्तविक उत्पादन बॉक्स (एसएस) को छूने से पहले ठीक से काम करता है।


मैंने वास्तव में कुछ सफलता के साथ अपना पहला दृष्टिकोण उपयोग किया है, लेकिन थोड़ा अलग तरीकों से मुझे लगता है कि आपकी कुछ समस्याएं हल हो जाएंगी:

  1. स्रोत स्कीम में इसे बनाने के लिए संपूर्ण स्कीमा और स्क्रिप्ट रखें ताकि कोई भी चेक आउट के बाद वर्तमान डेटाबेस स्कीमा बना सके। इसके अलावा, निर्माण प्रक्रिया के हिस्से द्वारा लोड की गई डेटा फ़ाइलों में नमूना डेटा रखें। जैसे-जैसे आप डेटा को खोजते हैं जो त्रुटियों का कारण बनता है, यह जांचने के लिए कि आपके त्रुटियों को फिर से उभरा नहीं है, इसे अपने नमूना डेटा में जोड़ें।

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

  3. मेरे समूह के लिए, उपयोगकर्ता इनपुट आवेदन स्तर (डीबी नहीं) पर किया जाता है, इसलिए यह मानक इकाई परीक्षणों के माध्यम से परीक्षण किया जाता है।

लोडिंग उत्पादन डेटाबेस कॉपी:
यह वह दृष्टिकोण था जिसका उपयोग मेरे आखिरी काम में किया गया था। यह कुछ मुद्दों का एक बड़ा दर्द कारण था:

  1. प्रतिलिपि उत्पादन संस्करण से पुरानी हो जाएगी
  2. परिवर्तन प्रतिलिपि की स्कीमा में किए जाएंगे और उत्पादन प्रणालियों के लिए प्रचारित नहीं होंगे। इस बिंदु पर हम स्कीमा को अलग कर देंगे। मज़ा नहीं।

डेटाबेस सर्वर का मज़ाक उड़ा रहा है:
हम यह भी अपने वर्तमान काम पर करते हैं। प्रत्येक प्रतिबद्धता के बाद हम नकली डीबी एक्सेसर्स इंजेक्शन वाले एप्लिकेशन कोड के खिलाफ यूनिट परीक्षण निष्पादित करते हैं। फिर दिन में तीन बार हम ऊपर वर्णित पूर्ण डीबी निर्माण निष्पादित करते हैं। मैं निश्चित रूप से दोनों दृष्टिकोणों की सिफारिश करता हूं।





mocking