स्वचालित परीक्षण डेटा के साथ महंगा रखरखाव

Question

मेरी कंपनी में, हमारे पास जावा वेब एप्लिकेशन में जुनीट का उपयोग करके एकीकरण परीक्षण का बढ़ता सेट है। प्रत्येक परीक्षण परीक्षण के लिए आवश्यक डेटा के साथ डेटाबेस को पॉप्युलेट करने के लिए कुछ विशिष्ट बाहरी एक्सएमएल फाइलों का उपयोग करता है। समस्या है:

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

यहाँ दृष्टिकोण के इस प्रकार के लिए लाभ में से कुछ हैं:

• आप crud परत पर उस डेटा सेटअप पर असर नहीं पड़ेगा साथ एक समस्या है करते हैं। जब कुछ गलत हो जाता है तो आपको प्रति त्रुटि एक परीक्षण विफलता मिलनी चाहिए, विफल होने वाले प्रत्येक संबंधित सेटअप के लिए एक त्रुटि नहीं।

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

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

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

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

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