जेपीए आधारित जुनीट टेस्ट बेस्ट प्रैक्टिस

Question

यह एक अजीब सवाल है, लेकिन यह मुझे कुछ महीनों के लिए परेशान कर रहा है। मैंने विकेट + हाइबरनेट (मेवेन के साथ निर्मित) का उपयोग करके एक जेपीए-आधारित वेब एप्लिकेशन बनाया है, और सीधे डीएओ परत का परीक्षण करना चाहता हूं। मैंने एक विशिष्ट स्रोत/परीक्षण/संसाधन/मेटा-आईएनएफ/persistence.xml फ़ाइल बनाई है जिसे मैंने परीक्षण के लिए उपयोग किया था, लेकिन डब्ल्यूटीपी और इसी तरह के संघर्षों में चल रहा है। इन मुद्दों को हल करने के लिए, मैंने एक अलग परीक्षण परियोजना बनाई जहां यूनिट परीक्षण लाइव रहते हैं। क्या एक जेपीए परियोजना के लिए यूनिट परीक्षणों को प्रबंधित करने का कोई बेहतर तरीका है बिना दृढ़ता फ़ाइलों के बीच युगल?

परिशिष्ट: क्या अन्य परीक्षण ढांचे (उदाहरण के लिए टेस्टएनजी) इसे आसान बनाते हैं?

Answer 1

आप mockito को आजमा सकते हैं। परीक्षण इस तरह काम करता है:

आप EntityManager "लागू करने" के लिए मॉकिटो का उपयोग करते हैं। वास्तविक कोड के बजाय, आप मॉकिटो के तरीकों का उपयोग यह कहने के लिए करते हैं कि "यदि एप्लिकेशन getReference() पर कॉल करता है, तो इस ऑब्जेक्ट को वापस करें"। पृष्ठभूमि में, mockito एक प्रॉक्सी उदाहरण बनाएगा जो जावा विधि कॉल को रोकता है और आपके द्वारा निर्दिष्ट मानों को वापस देता है। अन्य विधियों के लिए कॉल null लौटाएंगे।

createQuery() तरह मजाक बातें उसी तरह काम करता है, लेकिन आप पहले Query एक mockup बनाने और उसके बाद getReference() में के रूप में ही दृष्टिकोण (क्वेरी mockup वापसी) का उपयोग करने की जरूरत है।

चूंकि आप वास्तविक ईएम का उपयोग नहीं करते हैं, इसलिए आपको वास्तविक persistence.xml की आवश्यकता नहीं है।

यदि आप persistence.xml फ़ाइल का नाम बदलने के लिए कुछ संपत्ति सेट कर सकते हैं तो मुझे एक और अधिक सरल समाधान होगा, लेकिन मुझे नहीं लगता कि यह संभव है।

कुछ अन्य लिंक है कि मदद कर सकते हैं:

• How to configure JPA for testing in Maven
• Suggest a JPA Unit test framework

Answer 2

हम उत्पादन और परीक्षण runtimes के लिए दोहरी persistence.xml फ़ाइलों का उपयोग लेकिन यह केवल एक classpath संबंधित मुद्दा है (हम ग्रहण का उपयोग करते हैं लेकिन डब्ल्यूटीपी प्लगइन्स पर भरोसा नहीं करते हैं)। दोनों के बीच एकमात्र अंतर यह है कि उत्पादन संस्करण में इकाई परिभाषाएं नहीं हैं।

हम जेपीए का परीक्षण करने के लिए एक मॉकिंग फ्रेमवर्क का उपयोग नहीं करते क्योंकि यह हमारे परीक्षणों में कोई मूल्य नहीं जोड़ता है। परीक्षण जेपीए के साथ वास्तविक डेटा एक्सेस चलाते हैं जो PostgreSQL डेटाबेस से बात करता है।

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

वसंत परीक्षण ढांचा बहु-लेनदेन परीक्षण की अनुमति देने के लिए लचीला है लेकिन ये विशेष मामले हैं जो 10% से अधिक परीक्षण नहीं बनाते हैं।

हम अभी भी legacy support for JUnit 3.8 का उपयोग करते हैं लेकिन जुनीट 4 के लिए नया Spring TestContext Framework बहुत आकर्षक लग रहा है।

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

स्प्रिंग डी परीक्षणों को संक्षिप्त और आत्म-वर्णनात्मक बनाने में मदद करता है लेकिन यह एक महत्वपूर्ण विशेषता नहीं है।

Answer 3

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

और जैसा कि टॉपचेफ ने इंगित किया, वसंत के लेन-देन आधारित इकाई परीक्षण बहुत बढ़िया है।

Answer 4

जैसा कि यहां बताया गया है: http://www.devx.com/java/Article/36785/1954, वेब ऐप के साथ परीक्षण संसाधनों को तैनात करने से बचने के लिए आप अपनी परियोजना के .settings/org.eclipse.wst.common.component से निम्न पंक्तियां निकाल सकते हैं।

<wb-resource deploy-path="/WEB-INF/classes" source-path="/src/test/java"/> 
<wb-resource deploy-path="/WEB-INF/classes" source-path="/src/test/resources"/>