Junit4: पैरामीटरेटेड रन एनोटेशन से पहले और बाद में जोड़ें

@Before एनोटेशन पर एक पैरामीटर के बारे में कैसे: @Before(true) या @Before(onEachParameter = true)। निश्चित रूप से झूठे के लिए डिफ़ॉल्ट।

इस अनुरोध का लक्ष्य एक पैरामीटर रन निष्पादित होने से पहले और बाद में चलने वाले कोड को रखने के लिए एक जगह है। किसी दिए गए पैरामीटर में प्रत्येक परीक्षण से पहले नहीं चलता है। इस प्रकार आदेश बीपी बीटी टी1पी1 एटी बीटी टी2पी1 एटी बीटी टी3पी1 एटी एपी बीपी बीटी टी1पी2 एटी बीटी टी2पी2 एटी ... जहां

• बीपी पहले पैरामीटर रन विधि है @BeforeParameterRun
• बीटी पहले परीक्षण विधि है @ इससे पहले
• Txpy पैरामीटर y @Test पर xth टेस्ट है जैसे T2P3 पैरामीटर 3 पर टेस्ट 2 है
• एटी आफ्टर टेस्ट मेथड है @ आफ्टर
• एपी आफ्टर पैरामीटर रन है @AfterParameterRun

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

ऐसा लगता है कि विलय 3 अप्रैल 2009 के आसपास dsaff के एक पेड़ में हुआ था। टिप्पणियों में आप bigmikef से मर्ज देख सकते हैं। यह पुराना है, लेकिन उस समय काम किया।

दोस्तों, प्रत्येक पैरामीटरयुक्त रन के लिए "बाद/पहले" बहुत उपयोगी होगा।

यह नियमों का उपयोग करके किया जा सकता है, विशेष रूप से बाहरी संसाधन। प्रत्येक पैरामीटर के लिए कार्यान्वित विधियों को बुलाया जाता है:

@RunWith(Parameterized.class)
public class ParameterRuleTest {
    @Parameters()
    public static Iterable<Object[]> data() {
        return Arrays.asList(new Object[]{}, new Object[]{});
    }

    <strong i="6">@Rule</strong>
    public ExternalResource externalResource = new ExternalResource() {
        protected void before() throws Throwable { System.out.println("before"); }
        protected void after() { System.out.println("after"); }
    };

    <strong i="7">@Test</strong> public void myTest1() { System.out.println("test"); }
}

यह पैदा करता है

test
after
before
test
after

अगर यह स्वीकार्य है, तो कृपया इस मुद्दे को बंद करें।

@matthewfarwell मैं आपकी प्रतिक्रिया को गलत समझ सकता हूं, लेकिन उदाहरण में आपने प्रदान किया है कि नियम पैरामीटरयुक्त धावक द्वारा बनाए गए प्रत्येक उदाहरण के लिए प्रत्येक परीक्षण से पहले और बाद में चलेगा।

मुझे लगता है कि @bigmikef पैरामीटरयुक्त धावक द्वारा बनाए गए प्रत्येक उदाहरण के लिए एक बार पहले और बाद में विधि को चलाने में सक्षम होने की क्षमता चाहता था। मुझे नहीं लगता कि इस मामले में @ClassRule का उपयोग किया जा सकता है क्योंकि यह एक स्थिर संदर्भ में चलता है और सभी पैरामीटरयुक्त उदाहरणों के लिए केवल एक बार निष्पादित किया जाता है।

मुझे इसे लागू करने की पहल करने में कोई आपत्ति नहीं होगी क्योंकि यह मेरी वर्तमान परियोजना में फायदेमंद होगा। मेरा प्रस्ताव नीचे है:

कार्यान्वयन का सारांश:

जुनीट की पारंपरिक वास्तुकला जावा क्लास प्रति परीक्षण विधि का एक उदाहरण है। उपरोक्त आवश्यकताओं को लागू करने के लिए मेरा मानना ​​​​है कि Parameterized धावक को प्रत्येक पैरामीटरयुक्त उदाहरण के लिए एक जावा इंस्टेंस बनाने के लिए संशोधित करने की आवश्यकता है।

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

परिवर्धन / संशोधन:

org.junit.runners.Parameterized

• ParameterRule नामक एक नया एनोटेशन जोड़ें।
• एक नया संरक्षित आंतरिक वर्ग जोड़ें जो TestClassRunnerForParameters का विस्तार करता है जिसका नाम SingleInstanceRunnerForParameters है।
• ParameterRule मौजूद है या नहीं, इस पर निर्भर करते हुए TestClassRunnerForParameters या SingleInstanceRunnerForParameters तुरंत चालू करें।

org.junit.runners.BlockJUnit4ClassRunner

• परीक्षण वस्तु के निर्माण को methodBlock से बाहर ले जाएं। इसके बजाय परीक्षण वस्तु को पैरामीटर के रूप में प्रदान करें।
  
  
  
  • इसका मुख्य कारण यह है कि विस्तारित कक्षाएं अपने स्वयं के उदाहरण को methodBlock. में पारित कर सकती हैं अन्यथा यदि कोई BlockJUnit4ClassRunner का विस्तार करना चाहता है और अधिकांश कार्यक्षमता रखना चाहता है तो उन्हें निम्नलिखित विधियों की प्रतिलिपि बनाना होगा: withRules , withMethodRules , withTestRules और getMethodRules
  
  
• यदि परीक्षण वस्तु के निर्माण को methodBlock से बाहर ले जाना स्वीकार्य नहीं है, तो निम्न विधियों को निजी से संरक्षित में बदलने से कोड का दोहराव कम होगा:
  
  
  
  • withRules
  
  
  • withMethodRules
  
  
  • withTestRules
  
  
  • getMethodRules
  
  

org.junit.runners.Parameterized.SingleInstanceRunnerForParameters

• withParameterRules नाम की एक विधि जोड़ें जो $ ParameterRule द्वारा एनोटेट किए गए नियमों को निष्पादित करेगी।
• classBlock . के ओवरराइड संस्करण में classBlock withParameterRules निष्पादित करें

यदि इस कार्यान्वयन का एक उदाहरण प्रदान करने की प्राथमिकता है तो मैं अपने कांटे पर कर सकता हूं, लेकिन इससे पहले कि मैं एक महत्वपूर्ण राशि का निवेश करूं, मैं डिजाइन पर चर्चा करना चाहता था।

@coreyjv @matthewfarwell के उत्तर में क्या गलत है?

@ Tibor17 , उनके उत्तर पर मेरी प्रतिक्रिया देखें: https://github.com/KentBeck/junit/issues/45#issuecomment -11293228

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

उदाहरण के लिए यदि मेरे पास एक परीक्षण वर्ग है जिसे एक बार एक सामान्य सेटअप (वर्तमान में @ClassRule में स्थित) के साथ निष्पादित किया जाता है, तो पूरी कक्षा ~ 20 सेकंड में परीक्षणों को निष्पादित और पूरा करती है। हालांकि, अगर मैं सेटअप को एक विधि स्तर नियम में ले जाता हूं तो इसे निष्पादित करने और पूरा करने में लगभग ~ 240 सेकंड लगते हैं। वह सिर्फ एक वर्ग के लिए है। मेरी स्थिति में समय में वृद्धि स्वीकार्य नहीं है।

सैद्धांतिक रूप से मैं अपने सभी परीक्षणों को आवश्यक व्यवहार का अनुकरण करने के लिए एक ही विधि में रख सकता था लेकिन मुझे नहीं लगता कि यह एक रखरखाव योग्य परीक्षण डिजाइन है।

@ Tibor17 , मुझे यकीन नहीं है कि अगर अपडेट पर सूचनाएं निकलती हैं तो मैंने सोचा कि मैं एक और टिप्पणी करूंगा।

@dsaff , इस प्रस्ताव पर कोई विचार?

@coreyjv
मूल रूप से आप जो चाहते हैं वह @BeforeParams और @AfterParams जैसा कुछ है जो जीवनचक्र में केवल एक बार निष्पादित होता है। क्या मैं सही हू?

@ Tibor17 , अनिवार्य रूप से हाँ। मुझे लगता है कि मैं एक एकल एनोटेशन का उपयोग करूंगा जो नियमों को निष्पादित करने की अनुमति देता है।

अगर मैंने पहले क्लास (बीसी) और एसी का इस्तेमाल किया, तो क्या यह ऐसा दिखेगा?
बीसी बीपी बीटी टी1पी1 एटी बीटी टी2पी1 एटी बीटी टी3पी1 एटी एपी बीपी बीटी टी1पी2 एटी बीटी टी2पी2 एसी

@ Tibor17 , हाँ, मेरा मानना ​​है कि आपने जो प्रस्तुत किया है वह सटीक है।

@coreyjv
मुझे लगता है कि यह सुविधा जो आप चाहते हैं वह दिलचस्प हो सकती है। आपका वास्तविक उपयोग मामला क्या है?

@ टिबोर17
मैं वर्तमान में सेलेनियम का उपयोग करके एक वेब ब्राउज़र परीक्षण सूट बनाने पर काम कर रहा हूं ताकि परीक्षण केस निष्पादन के लिए जुनीट को खिलाए गए पृष्ठ सामग्री को नेविगेट और निरीक्षण किया जा सके।

मेरी ज़रूरतों के परिणामस्वरूप चीजों के परीक्षण के लिए प्रति पृष्ठ एक जुनीट टेस्ट क्लास हुई:

• क्या कोई क्षेत्र मौजूद है?
• क्या यह केवल पढ़ा जाता है?
• क्या लेबल टेक्स्ट "X" है?

ये पृष्ठ एप्लिकेशन के अंदर किसी भी मनमानी गहराई पर हो सकते हैं इसलिए मैंने "पहले" नियम (वर्तमान में @ClassRule) में गंतव्य पृष्ठ पर जाने के लिए नेविगेशनल लॉजिक रखा है। आदर्श रूप से, मैं एक ही परीक्षण को विभिन्न मापदंडों के साथ चलाना चाहता हूं, जिन्हें "सेटअप" में पढ़ा और उपयोग किया जाता है। ये पैरामीटर उपयोगकर्ता पहचानकर्ता और पासवर्ड क्रेडेंशियल और अन्य विवरण जैसे आइटम होंगे जो गंतव्य पृष्ठ पर जाने के लिए प्रासंगिक हैं।

मैं पिछली प्रतिक्रिया को उद्धृत करूंगा जो मैंने लिखा था कि मैं इसे "जीवनचक्र" के अनुसार क्यों करना चाहता हूं:

उदाहरण के लिए यदि मेरे पास एक परीक्षण वर्ग है जिसे एक बार एक सामान्य सेटअप (वर्तमान में @ClassRule में स्थित) के साथ निष्पादित किया जाता है, तो पूरी कक्षा ~ 20 सेकंड में परीक्षणों को निष्पादित और पूरा करती है। हालांकि, अगर मैं सेटअप को एक विधि स्तर नियम में ले जाता हूं तो इसे निष्पादित करने और पूरा करने में लगभग ~ 240 सेकंड लगते हैं। वह सिर्फ एक वर्ग के लिए है। मेरी स्थिति में समय में वृद्धि स्वीकार्य नहीं है।

@coreyjv
इसका मतलब है कि पैरा को नए एनोटेटेड सेटअप के भीतर भी दिखाना होगा।
यह जरूरतों का पूरा अवलोकन देता है।
जारी रखें।

@ Tibor17 , सेटअप में दिखाई देने वाले मापदंडों को सही करें। आप मुझे किस प्रकार का अतिरिक्त स्पष्टीकरण या विवरण देना चाहेंगे?

मुझे लगता है कि सिंहावलोकन और मेरी पिछली टिप्पणियां आवेदन की बारीकियों में जाने के बिना मेरी ज़रूरत की एक अच्छी तस्वीर प्रदान करती हैं (आप मेलिंग सूची भी देख सकते हैं) जो मुझे लगता है कि सीमित मूल्य जोड़ देगा।

@coreyjv
हो सकता है कि अब आप एक पुल को आगे बढ़ाएं और वहां के लोगों को भी इस मुद्दे में शामिल करें।

@ टिबोर17
यह मेरे साथ ठीक है मैं आगे बढ़ने से पहले "डिज़ाइन" पर प्रारंभिक अनुमोदन की तलाश में था।

@coreyjv
मैं कुछ परीक्षण देखने के लिए उत्सुक हूं जो उपयोग का वर्णन करता है, भले ही रनर का इम्प्लांट अधूरा हो।
दूसरे टेस्ट के बारे में क्या कहेंगे...

@ टिबोर17

दूसरे टेस्ट के बारे में क्या कहेंगे...

क्या आप मुझे एक नमूना परीक्षण कक्षा पोस्ट करने के लिए ढूंढ रहे हैं? यह वास्तव में बहुत उबाऊ है क्योंकि यह किसी भी अन्य पैरामीटरयुक्त परीक्षण की तरह है (जहां पैरामीटर उदाहरण के लिए डेटाबेस से पढ़े जाते हैं) और "जीवन चक्र" सेटअप का उपयोग @ClassRule या @Rule सेटअप के स्थान पर किया जाएगा। जैसा कि मैंने पहले उल्लेख किया है कि एक साधारण मामला सेटअप होगा जो उपयोगकर्ता नाम, पासवर्ड और एप्लिकेशन भूमिकाओं के विभिन्न संयोजनों का उपयोग करता है।

मुझे नहीं लगता कि यह सामान्य से बाहर है। यह सिर्फ इस मामले में है कि प्रत्येक विधि से पहले और बाद में सेटअप करना बेहद महंगा है।

@coreyjv

आपके परीक्षण में ऐसा करने के बारे में क्या?

@BeforeParameter
public void static setup() { // flag this call in some variable and assert it's set }

@ टिबोर17
जैसा कि मैंने पहले उल्लेख किया है कि इस सेटअप को पैरामीटरकृत करने की आवश्यकता है और @ पैरामीटर द्वारा लौटाए गए पैरामीटर के प्रत्येक सेट के लिए अद्वितीय होगा, इसलिए मुझे नहीं लगता कि दृष्टिकोण काम करेगा।

@coreyjv
मुझे लगता है कि आपके दिमाग में पहले से ही कुछ स्नैपशॉट कोड है।
क्या आप अभी भी इस पर यहां चर्चा करना चाहते हैं या आप एक पुल खोलना चाहते हैं?

@ टिबोर17
मैं इसे एक साथ रखूंगा और एक पुल अनुरोध जमा करूंगा। हो सकता है कि मैं इसे नए साल के बाद तक नहीं कर पाऊं लेकिन मैं देखूंगा कि मैं क्या कर सकता हूं। चर्चा के लिए धन्यवाद मैं इसकी सराहना करता हूं।

विचार:

1. हमें ऐसा होना चाहिए, और मुझे इच्छुक पार्टियों के साथ काम करने में खुशी हो रही है।
2. हम किसी भी संरक्षित तरीके के हस्ताक्षर नहीं बदल सकते। लेकिन एक संरक्षित विधि निकालना ब्लॉक (फ्रेमवर्क विधि विधि, ऑब्जेक्ट टेस्ट) एक बहुत अच्छा विचार की तरह लगता है।
3. ParameterRule इंटरफ़ेस लिखते समय, ध्यान रखें कि मुझे लगता है कि हमें रूल और क्लासरूल के काम करने के तरीके में सुधार करने की आवश्यकता है। https://docs.google.com/document/d/1B6Z45BSGsY08rZqe2KUZTJ3RVsnUE1-HcXjl5MFm9ls/edit यह समझाने में मदद करता है कि मैं चीजों को कहां आगे बढ़ते हुए देखना चाहता हूं: ParameterRule विशेष रूप से इस तरह के रूलफैक्ट्री दृष्टिकोण से लाभान्वित हो सकता है, क्योंकि यह आसान पुन: उपयोग की अनुमति देगा TemporaryFolder जैसी चीजों की।
4. मुझे लगता है कि हम पैरामीटरेटेड के तत्काल पैटर्न को एकतरफा रूप से नहीं बदल सकते हैं, क्योंकि वर्तमान परीक्षण एक-उदाहरण-प्रति-परीक्षण व्यवहार पर निर्भर हो सकते हैं। हम इसके आसपास कैसे काम कर सकते हैं?

ए। भिन्न व्यवहार को सक्षम करने के लिए एनोटेशन या एनोटेशन पैरामीटर जोड़ें।
बी। विभिन्न व्यवहार के साथ Parameterized का एक उपवर्ग बनाएँ।
सी। एक और विचार प्रत्येक परीक्षण के लिए परीक्षण वर्ग का एक नया उदाहरण बनाना होगा, लेकिन उस उदाहरण को उसी पैरामीटर ऑब्जेक्ट सरणी को पास करना होगा, जिसे पैरामीटर नियम द्वारा संचालित किया जा सकता है। यह शायद सबसे अधिक फायदेमंद होगा यदि मापदंडों को एक ही वस्तु में बांधा गया हो। एक संभावित पागल विचार पैरामीटर नियम को पैरामीटर वर्ग में ही संलग्न करना होगा ...

मुझे लगता है कि मैं सी से बी, और बी को ए पसंद करता हूं, लेकिन चर्चा के लिए खुला हूं।

@dsaff

हमें ऐसा होना चाहिए, और मुझे इच्छुक पार्टियों के साथ काम करने में खुशी हो रही है।

शुक्रिया!

हम किसी भी संरक्षित तरीके के हस्ताक्षर नहीं बदल सकते। लेकिन एक संरक्षित विधि निकालना ब्लॉक (फ्रेमवर्क विधि विधि, ऑब्जेक्ट टेस्ट) एक बहुत अच्छा विचार की तरह लगता है।

मैंने आज सुबह अपनी आवश्यकताओं को लागू किया, और मैंने इस विधि हस्ताक्षर को संशोधित नहीं किया (मैं निजी से कुछ आंतरिक तरीकों को बदलने के दृष्टिकोण के साथ गया -> संरक्षित)।

ParameterRule इंटरफ़ेस लिखते समय, ध्यान रखें कि मुझे लगता है कि हमें रूल और क्लासरूल के काम करने के तरीके में सुधार करने की आवश्यकता है। https://docs.google.com/document/d/1B6Z45BSGsY08rZqe2KUZTJ3RVsnUE1-HcXjl5MFm9ls/edit यह समझाने में मदद करता है कि मैं चीजों को कहां आगे बढ़ते हुए देखना चाहता हूं: ParameterRule विशेष रूप से इस तरह के रूलफैक्ट्री दृष्टिकोण से लाभान्वित हो सकता है, क्योंकि यह आसान पुन: उपयोग की अनुमति देगा TemporaryFolder जैसी चीजों की।

मैं इसे देख लूंगा और इसे ध्यान में रखूंगा।

मुझे लगता है कि हम पैरामीटरेटेड के तत्काल पैटर्न को एकतरफा रूप से नहीं बदल सकते हैं, क्योंकि वर्तमान परीक्षण एक-उदाहरण-प्रति-परीक्षण व्यवहार पर निर्भर हो सकते हैं। हम इसके आसपास कैसे काम कर सकते हैं?

मेरा कार्यान्वयन @ParameterRule एनोटेशन के अस्तित्व पर सशर्त है। यदि यह एक विधि का पता लगाता है या इस एनोटेशन के साथ फ़ील्ड को एनोटेट किया जाता है तो यह पैरामीटरेटेड के इंस्टेंटेशन पैटर्न को बदल देगा।

ए। भिन्न व्यवहार को सक्षम करने के लिए एनोटेशन या एनोटेशन पैरामीटर जोड़ें।

ऊपर देखो।

बी। विभिन्न व्यवहार के साथ Parameterized का एक उपवर्ग बनाएँ।

यह निश्चित रूप से उपवर्ग के रूप में लागू किया जा सकता है और मैं इसके साथ भी ठीक रहूंगा। मेरी विचार प्रक्रिया मौजूदा वर्ग के साथ काम करने की थी क्योंकि यह प्रवर्तक का इरादा प्रतीत होता था।

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

मुझे यकीन नहीं है कि मैं पूरी तरह से पालन करता हूं, लेकिन क्या मैं अभी भी एक सामान्य सेटअप रखने की आवश्यकता को प्राप्त कर सकता हूं जिसे @ पैरामीटर विधि से लौटाए गए पैरामीटर की प्रति सरणी एक बार निष्पादित किया जाता है?

क्या आप चाहते हैं कि मैं एक पुल अनुरोध सबमिट करूं ताकि हमारे पास चर्चा करने के लिए वास्तविक कोड हो?

@coreyjv , हाँ, मुझे लगता है कि यदि आपके पास कोड है तो आप साझा करने में प्रसन्न हैं, यह एक अच्छा अगला कदम है। धन्यवाद!

@dsaff

अच्छा लगता है, मैं कोशिश करूँगा और अगले कुछ दिनों में एक साथ पुल अनुरोध प्राप्त करूँगा।

@dsaff
@coreyjv

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

मेरे पास भी एक ऐसा मामला है जहां मैं 'आफ्टर पैरामीटर' फ़ंक्शन देखना चाहता हूं।

@coreyjv क्या यह कार्यक्षमता पाइपलाइन में है क्योंकि हम पैरामीटरेटेड टेस्ट केस चला रहे हैं जहां हमें ऐसी टिप्पणियों की आवश्यकता है। @BeforeParam और @AfterParam दोनों आवश्यक हैं।

@बिलेशग --

प्रति @dsaff इस अनुरोध को कुछ साल पहले 'मॉथबॉल' किया गया था। अगर वह इसे फिर से दिखाना चाहता है तो मैं उसे टाल देता हूं। इसके अतिरिक्त, मुझे यकीन नहीं है कि यह ऐसा कुछ है जो अब जुनीट 5 के लिए अधिक उपयुक्त होगा (मैंने वहां प्रगति के साथ नहीं रखा है)।

@coreyjv ठीक है। प्रतिक्रिया देने के लिये धन्यवाद। असल में, मुझे किसी और चीज के लिए इसकी आवश्यकता थी - पैरामीटर के अनुसार असफल परीक्षण केस गिनती प्राप्त करना। इस प्रश्न पर एक नज़र डालें।

मैं देखता हूं कि "@ BeforeParam /@AfterParam पैरामीटरेटेड रनर #1435 के लिए" विलय हो गया और 4.13 रिलीज नोट्स में जोड़ा गया। क्या इसका मतलब यह है कि 4.13 रिलीज होने वाली है? कब? मुझे इस कार्यक्षमता की सख्त जरूरत है! मैंने इसे जुनीट 5 में नहीं देखा, इसलिए मैं सोच रहा हूं कि मैं कब @BeforeParam/ @AFteParam के उपलब्ध होने की उम्मीद कर सकता हूं।

@dstaraster वर्तमान में अधिकांश JUnit टीम JUnit 5.0 को रिलीज़ करने पर ध्यान केंद्रित कर रही है। मुझे उम्मीद है कि इसके तुरंत बाद हम 4.13 रिलीज पर शुरू कर सकते हैं।

@kcooney मुझे इन @BeforeParam और @AfterParam एनोटेशन में भी बहुत दिलचस्पी है (और दुर्भाग्य से अभी तक मेरे हजारों परीक्षणों को JUnit5 में माइग्रेट करने के लिए तैयार नहीं है)।
क्या 4.13 रिलीज अभी भी अपेक्षित है?

@raubel I ने 4.13 रिलीज़ पर चर्चा करने के लिए #1496 खोला।

JUnit5 JUnit4-शैली परीक्षण चला सकता है, इसलिए आपको JUnit5 सुविधाओं का उपयोग करने के लिए अपने सभी परीक्षणों को माइग्रेट करने की आवश्यकता नहीं होगी।