2009-04-09 8 views
22

हमारी परियोजना में, हम मेवेन का उपयोग करके जून और कोबर्टुरा दोनों चलाते हैं। समस्या मैं का सामना करना पड़ रहा हूँ कि,मैवेन के साथ जूनिट और कोबर्टुरा चल रहा है

  1. JUnit परीक्षण मामलों Cobertura कवरेज रिपोर्ट पैदा करने के लिए एक बार फिर से एक बार जार बनाने की प्रक्रिया से पहले दो बार चल रहे हैं, और उसके बाद है। जब एंटी के साथ कोबर्टुरा और जूनिट चलते हैं, तो हम केवल एक बार जूनों को चलाते हैं, कोबर्टुरा जूनिट के साथ चलता है। उपरोक्त मामले को मैवेन के साथ कॉन्फ़िगर करने का कोई तरीका है। मुझे पता है कि हम जूनों को छोड़ने के लिए "maven.test.skip" संपत्ति का उपयोग कर सकते हैं। लेकिन जब मैं ऐसा करता हूं, तो मैं जूनिट एक्सएमएल और एचटीएमएल फाइल रिपोर्ट नहीं देख पा रहा हूं।
  2. इसके अलावा, मैवेन में बैच या समांतर में चलाने के लिए जूनिट को कॉन्फ़िगर कैसे करें?

धन्यवाद!

+0

आपका दूसरा प्रश्न वास्तव में एक अलग मुद्दा है, सीएनए को यहां दोबारा पोस्ट किया जाना प्रतीत होता है: http://stackoverflow.com/questions/423627/running-junit-tests-in-parallel –

उत्तर

22

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

+4

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

+0

इस तथ्य का जिक्र नहीं है कि उपकरण के बिना परीक्षण बहुत तेजी से चलते हैं। –

+0

@ डेविड वैलेरी: क्या आप कृपया चर्चा किए गए चर्चा धागे का लिंक प्रदान कर सकते हैं (बस हमारी पोस्ट संपादित करें)? –

1

कोबर्टूरा को संकलन स्कोप संदर्भ के रूप में जोड़ने का प्रयास करें। और अपने पोम के प्रासंगिक भागों को पोस्ट करें।

+3

निर्भरता के रूप में नहीं होगा संकलन गुंजाइश) केवल तभी मददगार हो सकता है जब आपकी परियोजना किसी भी तरह से कोबर्टूरा के ऊपर कुछ बनाने की कोशिश कर रही हो? शायद यह नहीं है कि अजय क्या ढूंढ रहे थे। –

1

ऐसा इसलिए होता है क्योंकि रिपोर्टिंग निष्पादन के लिए परीक्षण निष्पादन की आवश्यकता होती है ताकि यह रिपोर्ट बना सके। यदि साइट प्लगइन पर "साइट-केवल" लक्ष्य था, जिसमें @requiresDependencyResolution test एनोटेशन नहीं था, तो यह प्रोजेक्ट के prepare-package चरण तक सीमित हो सकता है और आपकी रिपोर्ट दो बार चलने वाले परीक्षणों के बिना उत्पन्न की जाएगी।

दुर्भाग्यवश ऐसा लगता है कि वर्तमान में ऐसा कोई लक्ष्य नहीं है (इस विषय पर मेरे question देखें)। वर्कअराउंड के विवरण के लिए प्रश्न का मेरा उत्तर देखें।

संबंधित मुद्दे