Testng: @Test(enable=false) वर्ग स्तर पर एनोटेशन कक्षा में सभी विधियों को अक्षम कर देना चाहिए

को निर्मित 21 दिस॰ 2011 · 20टिप्पणियाँ · स्रोत: cbeust/testng

http://code.google.com/p/testng/issues/detail?id=102 . से कॉपी किया गया

टेस्टएनजी 6.3.1 के साथ भी परीक्षण किया गया

कौन सा कदम फिर से समस्या पैदा कर देगा?
मेरे पास इस तरह की एक टेस्ट क्लास है:

@ टेस्ट (सक्षम = झूठा)
पब्लिक क्लास माईटेस्ट {
@DataProvider (नाम = "ब्ला")
निजी वस्तु [] [] bla () {
नई वस्तु लौटाएं [] [] {
नई वस्तु [] {"ब्ला"}
};
}

@ टेस्ट (डेटाप्रोवाइडर = "ब्ला")
सार्वजनिक शून्य विस्फोट (स्ट्रिंग ब्ला) {
System.out.println (bla);
}
}

कितने उत्पादन की अपेक्षा है?
मैं उम्मीद करता हूं कि विधि ब्लास्ट न चले और कोई कंसोल आउटपुट न हो। इसके बजाय ब्लास्ट "ब्ला" चलता है और प्रिंट करता है।

आप उत्पाद के किस संस्करण का उपयोग कर रहे हैं?
मैंने टेस्टिंग 5.11/6.0.1 के साथ परीक्षण किया है, मेवेन 2.2.1/3.0.3 से अचूक प्लगइन 2.7.2 के साथ चल रहा है।

कृपया अन्य अतिरिक्त जानकारी नीचे दें।

स्रोत

nithril

सभी 20 टिप्पणियाँ

हाय निकोलस,

आपको यह देखना चाहिए यदि आप अपने तरीकों पर किसी भी @Test विधि का उपयोग नहीं करते हैं, लेकिन जैसे ही आप करते हैं (जैसे आप डेटाप्रोवाइडर के साथ ऊपर अपने उदाहरण में करते हैं) तो enabled विशेषता ओवरराइड हो जाती है, और इसका डिफ़ॉल्ट सत्य है, इसलिए आप जो व्यवहार देख रहे हैं।

इसका कोई मतलब भी है क्या?

cbeust 21 दिस॰ 2011

हाँ, धन्यवाद सेड्रिक।

मैं गलत धारणा करता हूं कि कक्षा पर एनोटेशन @ टेस्ट (सक्षम = झूठा) पूरी तरह से कक्षा को निष्पादन से बाहर कर देता है

nithril 21 दिस॰ 2011

मैं मानता हूं कि यह थोड़ा सहज ज्ञान युक्त है, लेकिन अब इसे बदलने में बहुत देर हो चुकी है, दुख की बात है ...

cbeust 21 दिस॰ 2011

हाय, सेड्रिक!
@Test एनोटेशन में एक नया पैरामीटर जोड़ने के बारे में क्या है और इसे "
इस तरह हम पश्चगामी संगतता बनाए रखेंगे और एक ही समय में एक बहुत ही उपयोगी कार्यक्षमता प्रदान करेंगे।
यदि आप चाहें, तो मैं इसे स्वयं कार्यान्वित कर सकता हूं और एक पुल अनुरोध प्रदान कर सकता हूं।
अग्रिम में धन्यवाद!

andronix83 25 जून 2015

@ एंड्रॉइड 83 ,

मुझे डर है कि यह अब चीजों को और अधिक भ्रमित कर देता है कि आपको enabled और enabledClass बीच के सूक्ष्म अंतर को समझाने की आवश्यकता है।

वर्तमान enabled व्यवहार सबसे सहज नहीं है लेकिन यह सामान्य रूप से कोई मुद्दा नहीं लगता है, अगर मैं इस मुद्दे को कितनी बार लाया गया है (शायद ही कभी)।

cbeust 25 जून 2015

😕5 👎2

हाय सेड्रिक,

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

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

आदर्श रूप से, टेस्टएनजी जुनीट के http://junit.sourceforge.net/javadoc/org/junit/Ignore.html। लंबी कहानी छोटी, डेवलपर्स वास्तव में इस कार्यक्षमता की इच्छा कर रहे हैं।

धन्यवाद।

ecbrodie 1 अक्तू॰ 2015

@ecbrodie यह पहले से ही समर्थित है (इसे आज़माएं!) लेकिन एक चेतावनी है: प्रत्येक व्यक्तिगत विधि जिसमें @Test एनोटेशन है, परीक्षण को फिर से सक्षम करेगा।

@Test(enabled = false)
public class T {
  void f() {} // will not run
}

@Test(enabled = false)
public class T {
  <strong i="10">@Test</strong>
  void f() {} // WILL run!
}

यह शब्दार्थ के कारण है जो विधि स्तर पर विशेषता वर्ग स्तर पर परिभाषित विशेषताओं को ओवरराइड करता है, इसलिए विधि स्तर @Test एनोटेशन मूल रूप से @Test(enabled = true) कह रहा है क्योंकि यह डिफ़ॉल्ट मान है ...

समझ में आता है?

cbeust 2 अक्तू॰ 2015

👍1

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

आप @Test (सक्षम) शब्दार्थ के साथ लिए गए मूल दृष्टिकोण के प्रति कुछ तिरस्कार का संकेत देते हैं। यदि वास्तव में ऐसा है, तो क्यों न इसके शब्दार्थ को किसी ऐसी चीज़ में लाया जाए जो आपको अधिक सहज लगे?

ecbrodie 2 अक्तू॰ 2015

सहमत हूं, मुझे लगता है कि @Test(enabledClass = false) समझ में आएगा और पिछड़ी संगतता को तोड़े बिना आपके सुझाव को लागू करने का यही एकमात्र तरीका है। बहुत आसान भी होना चाहिए।

हो सकता है कि आप या @juherr पीआर सबमिट करने में रुचि रखते हों?

cbeust 2 अक्तू॰ 2015

मुझे यह अच्छा नहीं लग रहा है। मुझे एक नई विशेषता जोड़ने का विचार पसंद नहीं है जिसका उपयोग केवल कक्षा में किया जाता है।
फिर, मुझे लगता है कि enable=false स्रोत में उपयोग किए जाने पर एक बुरा अभ्यास है क्योंकि जब आप परीक्षण चलाना चाहते हैं तो आपको स्रोतों को संशोधित करना होगा।
IMO, यदि आप किसी वर्ग को अचयनित करना चाहते हैं, तो इसके बजाय testng.xml का उपयोग किया जाना चाहिए।
@ecbrodie आप अपने परीक्षण कैसे चलाते हैं?

बीटीडब्लू, इसके बजाय मैं जो प्रस्ताव करता हूं वह IAnnotationTransformer कार्यान्वयन प्रदान करना है जो कक्षा पर enable=false के डिफ़ॉल्ट व्यवहार को ओवरराइड करेगा।
IAnnotationTransformer पास केवल enable=false प्रत्येक परीक्षण है यदि उनकी कक्षा में enable=false ।
यह पिछड़ी संगतता को नहीं तोड़ेगा और एक विशिष्ट पैरामीटर नहीं जोड़ेगा।
@cbeust आपको क्या लगता है?

juherr 2 अक्तू॰ 2015

@juherr कूल पीआर, IAnnotationTransformer साथ करना वास्तव में बहुत आसान है।

मेरी एकमात्र चिंता यह है कि उपयोगकर्ता के लिए, यह उपयोग करने के लिए थोड़ा अधिक रहस्यमय है, जैसा कि enabledClass विशेषता के विपरीत है।

ध्यान दें कि हमारे पास पहले से ही कुछ विशेषताएं हैं जो केवल कक्षा स्तर ( suiteName , testName ) पर लागू होती हैं।

cbeust 2 अक्तू॰ 2015

जैसा कि मैंने कहा, मुझे उपयोग के मामले पसंद नहीं हैं। और मुझे लगता है कि यह केवल 2 व्यक्तियों के लिए पर्याप्त होगा जिन्होंने पिछले 4 वर्षों में इसे पूछा था :)

juherr 2 अक्तू॰ 2015

👎2

@juherr मेला काफी।

@ecbrodie आप पीआर के बारे में क्या सोचते हैं?

https://github.com/cbeust/testng/pull/816

cbeust 3 अक्तू॰ 2015

@cbeust
बस उत्सुक। क्या होगा यदि हम एक निर्मित एनोटेशनट्रांसफॉर्मर प्रदान करते हैं जो यह कर सकता है?

krmahadevan 8 नव॰ 2015

हाँ, यह वही है जो #816 प्रस्तावित करता है

juherr 8 नव॰ 2015

@ जुहेर
उस पीआर जानकारी को साझा करने के लिए धन्यवाद। किसी कारण से यह विलय की प्रतीक्षा कर रहा है?

krmahadevan 8 नव॰ 2015

क्या होगा यदि मेरे पास नीचे जैसा परिदृश्य है:

@Test(groups = { "regression", "smoke" }, dependsOnGroups = { "Creation" })
public class EditName {

    @Test(dataProvider="SomeTestData",dataProviderClass=SearchData.class)
    public void TC_1(String Msg) throws Exception{
        System.out.println(Msg);
    }

    @Test(dataProvider="SomeTestData",dataProviderClass=SearchData.class, dependsOnMethods = { "TC_1" }))
    public void TC_2(String Msg) throws Exception{
        System.out.println(Msg);
    }
}

क्या TC_1 और TC_2, प्रतिगमन और धूम्रपान समूह दोनों से संबंधित होंगे?
क्या TC_1 और TC_2 दोनों समूह "निर्माण" पर निर्भर करेंगे?
क्या TC_2 समूह "निर्माण" के साथ-साथ TC_1, या केवल TC_1 पर निर्भर होगा?

Rameshwar-Juptimath 2 फ़र॰ 2017

@ रामेश्वर-जुप्तिमठ आपके नमूने और इस मुद्दे के बीच क्या संबंध है?

juherr 2 फ़र॰ 2017

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

aliciatang 6 अप्रैल 2018

@aliciatang सभी एनोटेशन विशेषताओं के लिए व्यवहार समान है: विधि पर मान कक्षा के मानों को ओवरराइड कर देंगे।

6.13 से आप @Ignore उपयोग कर सकते हैं जो आप जिस व्यवहार की अपेक्षा करते हैं। @Ignore लिए प्रलेखन यहां पाया जा सकता

juherr 30 अप्रैल 2018

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स

Testng: @Test(enable=false) वर्ग स्तर पर एनोटेशन कक्षा में सभी विधियों को अक्षम कर देना चाहिए

सभी 20 टिप्पणियाँ

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