परीक्षण के लिए उपयोग किए गए डमी डेटा का प्रबंधन कैसे करते हैं? उन्हें अपनी संबंधित संस्थाओं के साथ रखें? एक अलग परीक्षण परियोजना में? उन्हें बाह्य संसाधनों से एक सीरिएलाइज़र के साथ लोड करें? या जहां भी जरूरत हो उन्हें फिर से बनाएँ?मॉड्यूलर एप्लिकेशन स्टैक में डमी डेटा और यूनिट परीक्षण रणनीतियों
हमारे पास प्रत्येक युक्त इकाइयों के साथ दूसरे मॉड्यूल के साथ कई मॉड्यूल के साथ एक एप्लिकेशन स्टैक है। प्रत्येक मॉड्यूल के अपने परीक्षण होते हैं और साथ चलने के लिए डमी डेटा की आवश्यकता होती है।
अब एक मॉड्यूल जिसमें बहुत से निर्भरताएं हैं, अन्य मॉड्यूल से बहुत सारे डमी डेटा की आवश्यकता होगी। हालांकि वे अपनी डमी ऑब्जेक्ट्स प्रकाशित नहीं करते हैं क्योंकि वे परीक्षण संसाधनों का हिस्सा हैं, इसलिए सभी मॉड्यूल को उन सभी डमी ऑब्जेक्ट्स को सेट करना होता है जिन्हें उन्हें बार-बार चाहिए।
इसके अलावा: हमारी संस्थाओं में सबसे अधिक क्षेत्रों ताकि वस्तु परत के खिलाफ भी चल लेनदेन व्यर्थ नहीं कर रहे हैं उन्हें कुछ मान होना चाहिए की आवश्यकता है, विशिष्टता, लंबाई, आदि
की तरह आगे सीमाओं के साथ समय के सबसे अधिक है वहाँ एक इस से सबसे अच्छा अभ्यास तरीका या सभी समाधान समझौता कर रहे हैं?
अधिक विस्तार
हमारे ढेर इस तरह दिखता है:
एक मॉड्यूल:
src/main/java --> gets jared (.../entities/*.java contains the entities)
src/main/resources --> gets jared
src/test/java --> contains dummy object setup, will NOT get jared
src/test/resources --> not jared
हम Maven का उपयोग निर्भरता को संभालने के लिए।
मॉड्यूल उदाहरण:
- मॉड्यूल एक कुछ डमी वस्तुओं है
- मॉड्यूल बी अपनी ही वस्तुओं और मॉड्यूल एक के रूप में ही
विकल्प एक की जरूरत है)
एक टेस्ट मॉड्यूल टी सभी डमी ऑब्जेक्ट्स को पकड़ सकता है और उन्हें सभी मॉड्यूल में सभी परीक्षणों के लिए टेस्ट स्कोप (इसलिए लोड निर्भरताएं नहीं मिलती हैं) प्रदान कर सकती हैं। क्या वह काम करेगा? अर्थ: अगर मैं एक में टी लोड और चलाने एक पर स्थापित यह होगा नहीं द्वारा टी विशेष रूप से नहीं बी शुरू की संदर्भ होते हैं? फिर भी एबी के डेटामैडेल के बारे में जानेंगे।
विकल्प ख)
मॉड्यूल एक जबकि एकके बारे में बी की डमी डेटा
पता नहीं है बी उन्हें प्राप्त करने के लिए अनुमति src/main/java../entities/dummy में कहीं डमी वस्तुओं प्रदान करता है विकल्प सी)
प्रत्येक मॉड्यूल में बाहरी संसाधन होते हैं जो क्रमबद्ध डमी ऑब्जेक्ट्स होते हैं। उन्हें परीक्षण पर्यावरण द्वारा deserialized किया जा सकता है कि उन्हें जरूरत है क्योंकि यह मॉड्यूल के लिए निर्भरता है जिसके वे संबंधित हैं। इसके लिए प्रत्येक मॉड्यूल को अपनी डमी ऑब्जेक्ट्स बनाने और क्रमबद्ध करने की आवश्यकता होगी हालांकि कोई ऐसा कैसे करेगा? यदि किसी अन्य इकाई परीक्षण के साथ यह इकाई परीक्षणों के बीच निर्भरता प्रस्तुत करता है जो कभी नहीं होना चाहिए या किसी स्क्रिप्ट के साथ इसे डिबग करना और लचीला नहीं होना मुश्किल होगा।
विकल्प घ)
एक नकली ढांचे का उपयोग करें और आवश्यकतानुसार प्रत्येक परीक्षा के लिए मैन्युअल रूप से आवश्यक फ़ील्ड आवंटित। यहां समस्या यह है कि हमारी संस्थाओं के अधिकांश क्षेत्र शून्य नहीं हैं और इस प्रकार सेटर्स या कन्स्ट्रक्टरों को बुलाया जाना चाहिए जो हमें फिर से शुरू में खत्म कर देंगे।
क्या हम
हम आवश्यक वस्तुओं 'संरचना लगातार बदल जाएगा के रूप में स्थिर डेटा के साथ एक स्थिर डेटाबेस स्थापित करने के लिए नहीं करना चाहते हैं नहीं करना चाहती। अभी बहुत कुछ, थोड़ी देर बाद। इसलिए हम सभी टेबल और कॉलम सेट अप करने के लिए हाइबरनेट चाहते हैं और यूनिट परीक्षण समय पर डेटा के साथ उनको भरें। इसके अलावा एक स्थिर डेटा बेस कई संभावित त्रुटियों और परीक्षण परस्पर निर्भरता का परिचय देगा।
क्या मेरे विचार सही दिशा में जा रहे हैं? परीक्षणों से निपटने के लिए सबसे अच्छा अभ्यास क्या है जिसके लिए बहुत सारे डेटा की आवश्यकता होती है? हमारे पास कई परस्पर निर्भर मॉड्यूल होंगे जिनके लिए कई अन्य मॉड्यूल से किसी प्रकार के डेटा से भरी वस्तुओं की आवश्यकता होगी।
संपादित
कैसे हम दूसरे जवाब के जवाब में अभी भी कर रहे हैं पर कुछ अधिक जानकारी:
तो सादगी के लिए, हम तीन मॉड्यूल है: Person, Product, Order। Person एक MockPerson वस्तु का उपयोग कर कुछ प्रबंधक तरीकों का परीक्षण होगा:
(व्यक्ति में/src/परीक्षण/जावा :)
public class MockPerson {
public Person mockPerson(parameters...) {
return mockedPerson;
}
}
public class TestPerson() {
@Inject
private MockPerson mockPerson;
public testCreate() {
Person person = mockPerson.mockPerson(...);
// Asserts...
}
}
MockPerson वर्ग पैक नहीं किया जाएगा।
एक ही उत्पाद टेस्ट मैचों के लिए लागू होता है:
(उत्पाद में/src/परीक्षण/जावा :)
public class MockProduct() { ... }
public class TestProduct {
@Inject
private MockProduct mockProduct;
// ...
}
MockProduct की जरूरत है लेकिन पैक नहीं किया जाएगा।
अब आदेश टेस्ट MockPerson और MockProduct की आवश्यकता होगी, इसलिए अब हम वर्तमान में दोनों बनाने के रूप में अच्छी तरह के रूप में MockOrderOrder का परीक्षण करने की जरूरत है।
(आदेश/src/परीक्षण/जावा में :)
इन डुप्लिकेट हैं और हर बार Person या Product बदलता है
public class MockProduct() { ... }
public class MockPerson() { ... }
यह केवल वर्ग है परिवर्तित करने की आवश्यकता होगी यह यहां होना चाहिए:
public class MockOrder() { ... }
public class TestOrder() {
@Inject
private order.MockPerson mockPerson;
@Inject
private order.MockProduct mockProduct;
@Inject
private order.MockOrder mockOrder;
public testCreate() {
Order order = mockOrder.mockOrder(mockPerson.mockPerson(), mockProduct.mockProduct());
// Asserts...
}
}
probl एम है, अब हमें person.MockPerson और order.MockPerson अपडेट करना होगा जब भी Person बदल दिया गया हो।
क्या मैक्स के साथ सिर्फ मोक्स प्रकाशित करना बेहतर नहीं है ताकि वैसे भी निर्भरता वाले हर दूसरे टेस्ट को मॉक.मॉक पर कॉल कर सकें और अच्छी तरह से सेटअप ऑब्जेक्ट प्राप्त कर सकें? या यह अंधेरा पक्ष है - आसान तरीका?
अरे cwash! कारखाने सूचक के लिए धन्यवाद। मुझे एक रेल ट्यूटोरियल में इसका उपयोग याद है;) यह समाधान हो सकता है, मुझे इसे और जांचना होगा। – Pete
@Pete - ठंडा, क्या आप एक नोट/अपडेट छोड़ सकते हैं जो हमें बता रहा है कि आपने क्या तय किया है? – cwash
तो, ऐसा लगता है कि हम इसे केंद्रीय डमी डेटा प्रदाता के रूप में उपयोग कर सकते हैं। अंत में हालांकि यह सिर्फ विकल्प ए है) जिसका अर्थ है कि कुछ बाहरी परियोजना में सभी आवश्यक डेटा जेनरेटर होंगे। अभी भी सोच रहा है कि क्या यह जाने का सबसे अच्छा तरीका है। इस पर कुछ और राय प्राप्त करने की उम्मीद है .. – Pete