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

346

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

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

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

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

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

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

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

— friedo
स्रोत

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

— dtc

मैं pesonally इस सवाल का यहाँ कोई आपत्ति नहीं है लेकिन अगर हम नियमों से जाना है, इस प्रश्न के लिए नहीं है stackoverflow बल्कि इसके लिए है softwareengineering.stackexchange वेबसाइट।

— ITExpert

155

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

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

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

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

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

— मार्क रॉडी
स्रोत

37

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

— डब्ल्यूडब्ल्यू।

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

— शीतदंश

2

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

— क्रॉस

2

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

— jedd.ahyoung

बेहतर उपयोग बंदर पैचिंग और

— मॉकिंग

56

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

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

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

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

— हारून दिगुल्ला
स्रोत

1

क्या इन-मेमोरी डीबी (विशेष रूप से) का उपयोग करने का एकमात्र कारण गति है?

— रिनोगो

2

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

— rinogo

1

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

— एरोन डिगुल्ला

@ ऐरन: हम इस रणनीति का भी पालन कर रहे हैं। मैं यह जानना चाहूंगा कि इन-मेमोरी मॉडल में यह सुनिश्चित करने के लिए आपकी रणनीति क्या है कि वास्तविक db की तुलना में समान संरचना है?

— गिलियूम

1

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

— हारून दिगुल्ला

14

मैं यह प्रश्न लंबे समय से पूछ रहा हूं, लेकिन मुझे लगता है कि इसके लिए कोई चांदी की गोली नहीं है।

वर्तमान में मैं क्या कर रहा हूं डीएओ ऑब्जेक्ट्स का मजाक उड़ा रहा है और उन वस्तुओं के एक अच्छे संग्रह की स्मृति प्रतिनिधित्व में रखता है जो डेटा के दिलचस्प मामलों का प्रतिनिधित्व करते हैं जो डेटाबेस पर रह सकते हैं।

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

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

भले ही कोई सवाल न हो लेकिन यह दृष्टिकोण आपकी कवरेज को बेहतर बनाता है, कुछ कमियां हैं, क्योंकि आपको अपने वर्तमान DBMS और एम्बेडेड प्रतिस्थापन दोनों के साथ काम करने के लिए ANSI SQL के जितना करीब होना संभव है।

कोई फर्क नहीं पड़ता कि आपको क्या लगता है कि आपके कोड के लिए अधिक प्रासंगिक है, वहाँ कुछ परियोजनाएं हैं जो इसे आसान बना सकती हैं, जैसे DbUnit ।

— kolrie
स्रोत

13

यहां तक कि अगर वहाँ उपकरण है कि आप एक ही रास्ता या किसी अन्य रूप में अपने डेटाबेस उपहास करने के लिए अनुमति देते हैं (उदाहरण के लिए jOOQ की MockConnectionहै, जो में देखा जा सकता इस उत्तर - त्याग, मैं jOOQ के विक्रेता के लिए काम करते हैं), मैं सलाह होगा नहीं जटिल के साथ बड़ा डेटाबेस उपहास करने के लिए प्रश्नों।

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

वाक्य - विन्यास
जटिलता
गण (!)

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

— लुकास ईडर
स्रोत

5

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

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

— डेव शेरोहमान
स्रोत

3

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

डीएओ के लिए परीक्षण चलाने के लिए आवश्यक सब कुछ स्रोत नियंत्रण में है। इसमें DB बनाने के लिए स्कीमा और स्क्रिप्ट शामिल हैं (docker इसके लिए बहुत अच्छा है)। यदि एम्बेडेड DB का उपयोग किया जा सकता है - मैं इसे गति के लिए उपयोग करता हूं।

अन्य वर्णित दृष्टिकोणों के साथ महत्वपूर्ण अंतर यह है कि परीक्षण के लिए आवश्यक डेटा SQL स्क्रिप्ट या XML फ़ाइलों से लोड नहीं है। सब कुछ (कुछ शब्दकोश डेटा को छोड़कर जो प्रभावी रूप से स्थिर है) उपयोगिता कार्यों / कक्षाओं का उपयोग करके एप्लिकेशन द्वारा बनाया गया है।

मुख्य उद्देश्य परीक्षण द्वारा उपयोग किए गए डेटा को बनाना है

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

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

क्या यह व्यवहार में इसका मतलब है के कुछ विचार दे करने के लिए, कुछ डीएओ जो साथ काम करता है के लिए परीक्षण पर विचार Commentकरने के लिए रों Postद्वारा लिखित रों Authors। ऐसे DAO के लिए CRUD संचालन का परीक्षण करने के लिए DB में कुछ डेटा बनाए जाने चाहिए। परीक्षण की तरह दिखेगा:

@Test
public void savedCommentCanBeRead() {
    // Builder is needed to declaratively specify the entity with all attributes relevant
    // for this specific test
    // Missing attributes are generated with reasonable values
    // factory's responsibility is to create entity (and all entities required by it
    //  in our example Author) in the DB
    Post post = factory.create(PostBuilder.post());

    Comment comment = CommentBuilder.comment().forPost(post).build();

    sut.save(comment);

    Comment savedComment = sut.get(comment.getId());

    // this checks fields that are directly stored
    assertThat(saveComment, fieldwiseEqualTo(comment));
    // if there are some fields that are generated during save check them separately
    assertThat(saveComment.getGeneratedField(), equalTo(expectedValue));        
}

SQL स्क्रिप्ट या XML फ़ाइलों पर परीक्षण डेटा के साथ इसके कई फायदे हैं:

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

रोलबैक बनाम कमिट

मुझे यह अधिक सुविधाजनक लगता है कि परीक्षण तब किए जाते हैं जब वे निष्पादित होते हैं। सबसे पहले, कुछ प्रभाव (उदाहरण के लिए DEFERRED CONSTRAINTS) की जाँच नहीं की जा सकती है अगर कभी ऐसा न हो। दूसरे, जब कोई परीक्षण विफल हो जाता है तो डेटा को DB में जांचा जा सकता है क्योंकि यह रोलबैक द्वारा वापस नहीं किया जाता है।

इस कारण से एक नकारात्मक पहलू यह है कि परीक्षण एक टूटे हुए डेटा का उत्पादन कर सकता है और यह अन्य परीक्षणों में विफलताओं को जन्म देगा। इससे निपटने के लिए मैं परीक्षणों को अलग करने की कोशिश करता हूं। ऊपर दिए गए उदाहरण में हर परीक्षा नई हो सकती है Authorऔर अन्य सभी निकाय इससे संबंधित बनाए जाते हैं ताकि टकराव कम हो। संभावित रूप से तोड़े जा सकने वाले शेष आक्रमणकारियों से निपटने के लिए लेकिन एक DB स्तर की कमी के रूप में व्यक्त नहीं किया जा सकता है मैं गलत परिस्थितियों के लिए कुछ प्रोग्रामेटिक चेक का उपयोग करता हूं जो कि हर एक परीक्षण के बाद चलाए जा सकते हैं (और वे CI में चलाए जाते हैं लेकिन आमतौर पर प्रदर्शन के लिए स्थानीय रूप से स्विच किए जाते हैं कारणों)।

— रोमन कोनोवल
स्रोत

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

— दारमासला

तो स्पष्टीकरण के लिए: क्या आप अपने आवेदन के दौरान उपयोगिता कार्यों / कक्षाओं का उपयोग कर रहे हैं, या सिर्फ अपने परीक्षणों के लिए?

— एला

@ इन उपयोगिता कार्यों को आमतौर पर परीक्षण कोड के बाहर की आवश्यकता नहीं होती है। उदाहरण के लिए सोचें PostBuilder.post()। यह पोस्ट की सभी अनिवार्य विशेषताओं के लिए कुछ मान उत्पन्न करता है। उत्पादन कोड में इसकी आवश्यकता नहीं है।

— रोमन कोनोवल

2

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

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

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

Acolyte मेरा ढांचा है जिसमें एक JDBC ड्राइवर और इस तरह के मॉकअप के लिए उपयोगिता शामिल है: http://acolyte.eu.org ।

— cchantep
स्रोत