Testng: @ सुपर क्लास से टेस्ट विधियों को प्रत्येक उप वर्ग के लिए फिर से निष्पादित किया जाता है

@vlad230

गीथब मुद्दों में पीएस संपादन कोड अविश्वसनीय रूप से खराब है ... कृपया किसी और चीज़ पर जाएं।

आप मार्कडाउन से खुद को परिचित कराने के लिए कुछ समय बिताना चाह सकते हैं। इससे फ़ॉर्मेटिंग के साथ कोड स्निपेट जोड़ना बहुत आसान हो जाएगा।

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

@juherr - आपके विचार?

@krmahadevan स्वरूपण के लिए धन्यवाद :)

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

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

डिजाइन के रूप में काम कर रहा है।
आप अपनी कक्षा में baseMethod परीक्षण क्यों नहीं स्थानांतरित करते?

@vlad230

यदि आप मुझसे पूछें, तो सुपर क्लास में कई बार परीक्षणों को निष्पादित करने का कोई मतलब नहीं होगा।

आप वास्तव में क्या हासिल करने की कोशिश कर रहे हैं? यह बहुत अच्छा होगा यदि आप कृपया अपने परिदृश्य को विस्तृत करने या समझाने में मदद कर सकें।

यदि यह अभी टेस्टएनजी का अपेक्षित व्यवहार है, तो शायद हम इसे सुधार के रूप में जोड़ सकते हैं।

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

1. क्या आपका बेस क्लास org.testng.IHookable
2. इसकी run() विधि के भीतर, एक संपादन चेक जोड़ें जो यह जांच करेगा कि क्या बेस क्लास विधि पहले से ही निष्पादित है और निष्पादित नहीं होने पर इसे चलाती है।

यहाँ एक नमूना है

मार्कर इंटरफ़ेस जो इंगित करता है कि बेस क्लास विधि केवल एक बार चलनी चाहिए

import static java.lang.annotation.ElementType.METHOD;
import static java.lang.annotation.ElementType.TYPE;

import java.lang.annotation.Retention;
import java.lang.annotation.Target;

@Retention(java.lang.annotation.RetentionPolicy.RUNTIME)
@Target({METHOD, TYPE})
public <strong i="20">@interface</strong> RunOnce {
}

ये है स्टेट ट्रैकर सिंगलटन

import java.lang.reflect.Method;
import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;

public class StateTracker {

  private static final StateTracker instance = new StateTracker();

  private final Map<String, Object> runOnceData = new ConcurrentHashMap<>();

  private StateTracker() {}

  public static StateTracker getInstance() {
    return instance;
  }

  boolean canExecute(Method method) {
    RunOnce runOnce = method.getAnnotation(RunOnce.class);
    String methodName = method.getName();
    boolean execute = true;
    if (runOnce != null) {
      if (runOnceData.containsKey(methodName)) {
        execute = false;
      } else {
        runOnceData.put(methodName, new Object());
      }
    }
    return execute;
  }
}

यहां बताया गया है कि बेस क्लास कैसा दिखेगा

import org.testng.IHookCallBack;
import org.testng.IHookable;
import org.testng.ITestResult;
import org.testng.annotations.Test;

public class BaseTest implements IHookable {

  <strong i="27">@Test</strong>
  <strong i="28">@RunOnce</strong>
  public void baseclassTestMethod() {
    System.err.println("Base class test method executed");
  }

  <strong i="29">@Override</strong>
  public void run(IHookCallBack callBack, ITestResult testResult) {
    boolean execute =
        StateTracker.getInstance()
            .canExecute(testResult.getMethod().getConstructorOrMethod().getMethod());
    if (execute) {
      callBack.runTestMethod(testResult);
    } else {
      testResult.setStatus(ITestResult.SKIP);
      testResult.setThrowable(new RuntimeException("Intentionally skipping"));
    }
  }
}

यहां बताया गया है कि बच्चों की कक्षाएं कैसी दिखाई देंगी

import org.testng.annotations.Test;

public class ChildClass1 extends BaseTest {

  <strong i="33">@Test</strong>
  public void childTest() {
    System.err.println(getClass().getName() + ".childTest() executed");
  }
}

import org.testng.annotations.Test;

public class ChildClass2 extends BaseTest {

  <strong i="36">@Test</strong>
  public void childTest() {
    System.err.println(getClass().getName() + ".childTest() executed");
  }
}

आपको कुछ फ़िल्टरिंग तंत्र जोड़ने की आवश्यकता होगी जो परीक्षण के परिणामों को छांटता है और छोड़े गए परीक्षणों को हटा देता है जिन्हें @RunOnce का उपयोग करके एनोटेट किया जाता है

@krmahadevan
आप वास्तव में क्या हासिल करने की कोशिश कर रहे हैं? यह बहुत अच्छा होगा यदि आप कृपया अपने परिदृश्य को विस्तृत करने या समझाने में मदद कर सकें।

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

@krmahadevan विस्तृत समाधान के लिए बहुत बहुत धन्यवाद लेकिन यह मेरे लिए थोड़ा बोझिल लग रहा है। चूंकि टेस्टएनजी को अनुकूलित किया जा सकता है, इसलिए मैं इसे डिफ़ॉल्ट व्यवहार के रूप में देखूंगा।
मुझे बेस क्लास से परीक्षणों को लगातार पुन: निष्पादित करने की आवश्यकता नहीं दिख रही है। यदि यह सेटअप की बात है / टियरडाउन हमेशा @ / @After इससे पहले कि आधार वर्ग से एक बच्चे को कक्षा से पहले फिर से मार डाला हर बार होगा इस्तेमाल कर सकते हैं।

हां, मुझे लगता है कि व्यवहार विन्यास योग्य हो सकता है।

वास्तव में, मुझे ऐसा उपयोग केस नहीं मिला जहां हम प्रत्येक बच्चे के उदाहरण के लिए पैरेंट टेस्ट चलाना चाहते हैं।
जब तक आपके पास परीक्षण करने के लिए प्रत्यक्ष निर्भरता न हो ( dependsOnMethods ) क्योंकि परीक्षण स्थिति को अक्सर एकीकरण परीक्षणों में उसी तरह संशोधित किया जाता है।

@krmahadevan WDYT?

@vlad230

विस्तृत समाधान के लिए बहुत बहुत धन्यवाद लेकिन यह मेरे लिए थोड़ा बोझिल लग रहा है

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

चूंकि टेस्टएनजी को अनुकूलित किया जा सकता है, इसलिए मैं इसे डिफ़ॉल्ट व्यवहार के रूप में देखूंगा।

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

मुझे बेस क्लास से परीक्षणों को लगातार पुन: निष्पादित करने की आवश्यकता नहीं दिख रही है। यदि यह सेटअप की बात है / टियरडाउन हमेशा इस्तेमाल कर सकते हैं @ से पहले / @after कि फिर से मार डाला आधार वर्ग से एक बच्चे को कक्षा से पहले हर बार होगा।

मेरे लिए चीजों को देखने का यह सिर्फ एक तरीका है। यदि किसी विशेष विधि को हर बार निष्पादित नहीं किया जाना चाहिए, तो आपको @Test एनोटेशन का उपयोग नहीं करना चाहिए। आप कॉन्फ़िगरेशन एनोटेशन का बहुत अच्छी तरह से उपयोग कर सकते हैं जैसे @BeforeTest (जो प्रति <test> टैग में केवल एक बार निष्पादित होता है) या @BeforeSuite (जो प्रति <suite> केवल एक बार निष्पादित होता है)

मुझे यकीन नहीं है, अगर आपकी बेस क्लास में आपकी टेस्ट विधियां वास्तव में टेस्ट विधियां हैं। मेरे लिए वे कॉन्फ़िगरेशन की तरह अधिक ध्वनि करते हैं जो परीक्षण को चलाने के लिए संतुष्ट होने के लिए सेटअप शर्तों को स्थापित करते हैं।

@juherr - मुझे पूरा यकीन नहीं है कि मैं यहां उपयोग के मामले से सहमत हूं। एक परीक्षण चाहे वह कहीं भी पाया जाए, निष्पादित किया जाना है। यदि ऐसा कोई परिदृश्य है जिसमें हम नहीं चाहते कि इसे सभी बाल वर्गों के लिए निष्पादित किया जाए, तो हमें कॉन्फ़िगरेशन एनोटेशन का उपयोग करना चाहिए, न कि @Test एनोटेशन का।

कार्यान्वयन के पक्ष में, मुझे लगता है कि यह कोडबेस में बहुत अधिक अराजकता जोड़ देगा, खासकर जब लोग निष्पादन के साधन के रूप में समूहों का उपयोग करना शुरू कर देते हैं।

इसके अलावा, मुझे लगता है कि वर्तमान में टेस्टएनजी के भीतर ऐसा करने का एक तरीका है (जिसे मैंने एक उदाहरण के रूप में साझा किया है)। क्यों न केवल इसका लाभ उठाएं? ऐसा लगता है कि यह एक बार इस्तेमाल होने वाला मामला है, और टेस्टएनजी का उपयोग करने के नियमित तरीके से फिट नहीं लगता है।

@krmahadevan मुझे क्षमा करें, लेकिन मुझे लगता है कि आप समझ नहीं पाए कि मैं क्या करने की कोशिश कर रहा हूं।
मेरे मूल वर्ग (बेसटेस्ट - जैसे डैशबोर्डटेस्ट) में मेरे पास अब 15 परीक्षण हैं और मेरे पास 3 बाल वर्ग हैं (उदाहरण के लिए डैशबोर्डफिल्टरटेस्ट, डैशबोर्डट्रीटेस्ट, डैशबोर्डएडिटरटेस्ट) जिनमें प्रत्येक के अंदर परीक्षण हैं। मेरे पोस्ट में वर्णित दृष्टिकोण का उपयोग करते हुए, हर बार जब मैं परीक्षण चलाता हूं, तो उन 15 परीक्षणों को 3 बार निष्पादित किया जाता है (इसलिए, 3x15 = 45 परीक्षण निष्पादित किए जा रहे हैं) कोई मूल्य नहीं लाते हैं और रन टाइम को बेकार में बढ़ाते हैं, जैसा कि केवल निष्पादित करने के विपरीत है एक बार 15 परीक्षण।

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

अगर ऐसा नहीं किया जा सकता है, तो मैं समझता हूं। फिर भी धन्यवाद।

@vlad230

अतिरिक्त संदर्भ जोड़ने के लिए धन्यवाद।

मेरे मूल वर्ग (बेसटेस्ट - जैसे डैशबोर्डटेस्ट) में मेरे पास अब 15 परीक्षण हैं और मेरे पास 3 बाल वर्ग हैं (उदाहरण के लिए डैशबोर्डफिल्टरटेस्ट, डैशबोर्डट्रीटेस्ट, डैशबोर्डएडिटरटेस्ट) जिनमें प्रत्येक के अंदर परीक्षण हैं। मेरे पोस्ट में वर्णित दृष्टिकोण का उपयोग करते हुए, हर बार जब मैं परीक्षण चलाता हूं, तो उन 15 परीक्षणों को 3 बार निष्पादित किया जाता है (इसलिए, 3x15 = 45 परीक्षण निष्पादित किए जा रहे हैं) कोई मूल्य नहीं लाते हैं और रन टाइम को बेकार में बढ़ाते हैं, जैसा कि केवल निष्पादित करने के विपरीत है एक बार 15 परीक्षण।

उस स्थिति में, DashboardFilterTest, DashboardTreeTest, DashboardEditorTest का विस्तार DashboardTest क्यों होगा? ऐसा लगता है कि DashboardTest परीक्षणों को यहां विरासत दृष्टिकोण का लाभ उठाने के बजाय अपनी कक्षा में रहने की आवश्यकता है? सभी सामान्य परीक्षण विधियों को हटाने के लिए बेस क्लास को फिर से तैयार किया जाना चाहिए और एक अलग टेस्ट क्लास में रखा जाना चाहिए, और डैशबोर्डटेस्ट को केवल सामान्य गैर @Test विधियों के लिए दोबारा नहीं किया जाना चाहिए?

अगर ऐसा नहीं किया जा सकता है, तो मैं समझता हूं। फिर भी धन्यवाद।

यह इस बारे में नहीं है कि उन्हें किया जा सकता है या नहीं (कार्यान्वयन चुनौतियां एक अलग विषय है), लेकिन मुझे अभी भी उपयोग के मामले की वैधता को समझने की कोशिश करने में कठिनाई हो रही है।

@krmahadevan

उस स्थिति में, DashboardFilterTest, DashboardTreeTest, DashboardEditorTest का विस्तार DashboardTest क्यों होगा? ऐसा लगता है कि DashboardTest परीक्षणों को यहां विरासत दृष्टिकोण का लाभ उठाने के बजाय अपनी कक्षा में रहने की आवश्यकता है? सभी सामान्य परीक्षण विधियों को हटाने के लिए बेस क्लास को फिर से तैयार किया जाना चाहिए और एक अलग टेस्ट क्लास में रखा जाना चाहिए, और डैशबोर्डटेस्ट को केवल सामान्य गैर @Test विधियों के लिए दोबारा नहीं किया जाना चाहिए?

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

निश्चित रूप से, मेरे पास एक गैर- @ टेस्ट टेस्ट क्लास हो सकता है (हालांकि यह अजीब होगा और कोई गलती से यहां परीक्षण जोड़ सकता है) लेकिन यह सिर्फ इस मुद्दे से बचने के लिए होगा, है ना?

@vlad230

'डैशबोर्डटेस्ट' में सहायक विधियां शामिल हैं (उदाहरण के लिए ओपनडैशबोर्ड (), क्रिएटडैशबोर्ड () आदि) और सेटअप/टियरडाउन/क्लीनअप (@ इससे पहले/@ बाद में) विधियां जो कि बाल कक्षाओं के लिए भी आवश्यक हैं। इसलिए, मुझे बाल कक्षाओं में कोड को दोहराने की आवश्यकता नहीं है।

यह समझ में आता है। और हाँ वे बेस क्लास के भीतर बहुत अच्छी तरह से निवास कर सकते हैं ताकि कॉन्फ़िगरेशन विधियों को बाल वर्गों के लिए भी उपलब्ध कराया जा सके।

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

आप अभी भी GenericDashboardTest extends DashboardTest नामक एक वर्ग बना सकते हैं जिसमें सभी सामान्य @Test विधियां शामिल हैं।

निश्चित रूप से, मेरे पास एक गैर- @ टेस्ट टेस्ट क्लास हो सकता है (हालांकि यह अजीब होगा और कोई गलती से यहां परीक्षण जोड़ सकता है) लेकिन यह सिर्फ इस मुद्दे से बचने के लिए होगा, है ना?

खैर, यह नहीं है कि कौन सी कोड समीक्षाएं हैं :) इस तरह की फिसलन को रोकने के लिए। बेस क्लास (जो आपने समझाया है) में सामान्य जेनेरिक @Test विधियों को शामिल करने की आवश्यकता नहीं है। यह बहुत अच्छी तरह से सिर्फ सहायकों और विन्यासों को घर कर सकता है और आपके पास एक और परीक्षण वर्ग हो सकता है जो आधार वर्ग का विस्तार करता है और सामान्य परीक्षण विधियों को रखता है। इससे हाथ में भ्रम का समाधान होना चाहिए।

_डिज़ाइन के रूप में कार्य करना_ के रूप में समाधान के साथ इस समस्या को समाप्त करना