JUnit4 में विशिष्ट क्रम में परीक्षण विधियों को कैसे चलाया जाए?


413

मैं परीक्षण विधियों को निष्पादित करना चाहता हूं जो @Testविशिष्ट क्रम में एनोटेट किए गए हैं ।

उदाहरण के लिए:

public class MyTest {
    @Test public void test1(){}
    @Test public void test2(){}
}

मैं हर बार दौड़ने test1()से पहले दौड़ना सुनिश्चित करना चाहता test2()हूं MyTest, लेकिन मुझे एनोटेशन पसंद नहीं आया @Test(order=xx)

मुझे लगता है कि यह JUnit के लिए काफी महत्वपूर्ण विशेषता है, अगर JUnit के लेखक ऑर्डर सुविधा नहीं चाहते हैं , तो क्यों?


2
वे मुझे स्रोत फ़ाइल में दिखाई देने वाले क्रम में निष्पादित होने लगते हैं।
लोर्ने

84
आपको उन परीक्षणों को कभी नहीं लिखना चाहिए जिन्हें एक निर्दिष्ट क्रम में निष्पादित करने की आवश्यकता है। यह वास्तव में बुरा अभ्यास है। प्रत्येक परीक्षण स्वतंत्र चलाने में सक्षम होना चाहिए।
एपफैलासट

5
@ ईजेपी यह लगभग सार्वभौमिक था जावा प्री 7. प्री 7, ज्यादातर जेवीएम ने ऐसा किया था, लेकिन इसकी गारंटी कभी नहीं थी। जावा 7 जेवीएम गैर-नियतात्मक क्रम में विधियों को वापस कर सकते हैं।
मैथ्यू फरवेल

17
चारों ओर काम करना। आप परीक्षण मामलों से @ हटाएं, उन्हें निजी कार्यों के रूप में रूपांतरित करें, फिर एकल परीक्षण केस क्रिएट करें, और निजी कार्यों को क्रम में बुलाएं।
सिमोन गुओ

12
परीक्षण मामलों से @Test हटाने से JUnit रिपोर्ट गड़बड़ हो जाएगी। वैसे, एक विशिष्ट आदेश लागू करना यूनिट परीक्षणों के लिए एक बुरा अभ्यास है, लेकिन जरूरी नहीं कि एकीकरण परीक्षणों के लिए एक बुरा अभ्यास हो । सबसे अच्छा विकल्प नहीं है (आदर्श) के साथ वर्ग पर टिप्पणी करने के लिए है @FixMethodOrder(MethodSorters.NAME_ASCENDING), रखने के @Testसभी परीक्षण तरीकों के लिए एनोटेशन और उन्हें वर्णानुक्रम का नाम बदलने के निष्पादन की इच्छित क्रम पर निर्भर करता है, उदाहरण के लिए t1_firstTest(), t2_secondTest()आदि
MisterStrickland

जवाबों:


238

मुझे लगता है कि यह JUnit के लिए काफी महत्वपूर्ण विशेषता है, अगर JUnit के लेखक ऑर्डर सुविधा नहीं चाहते हैं, तो क्यों?

मुझे यकीन नहीं है कि JUnit के साथ ऐसा करने का एक साफ तरीका है, मेरी जानकारी के लिए JUnit मानता है कि सभी परीक्षणों को एक मनमाना क्रम में किया जा सकता है। सामान्य प्रश्न से:

मैं एक परीक्षण स्थिरता का उपयोग कैसे करूं?

(...) परीक्षण-विधि इनवोकेशन के आदेश की गारंटी नहीं है , इसलिए testOneItemCollection () को testEmptyCollection () से पहले निष्पादित किया जा सकता है। (...)

ऐसा क्यों है? वैसे, मेरा मानना ​​है कि परीक्षण के आदेश को निर्भर बनाना एक अभ्यास है जिसे लेखक बढ़ावा नहीं देना चाहते हैं। परीक्षण स्वतंत्र होना चाहिए, उन्हें युग्मित नहीं किया जाना चाहिए और इसका उल्लंघन करने से चीजें बनाए रखने में मुश्किल होगी, व्यक्तिगत रूप से परीक्षण चलाने की क्षमता को तोड़ देगी (जाहिर है, आदि)।

यह कहा जा रहा है, यदि आप वास्तव में इस दिशा में जाना चाहते हैं, तो TestNG का उपयोग करने पर विचार करें क्योंकि यह मूल रूप से किसी भी मनमाने ढंग से आदेश में परीक्षण विधियों का समर्थन करता है (और यह निर्दिष्ट करने की तरह कि विधियाँ तरीकों के समूहों पर निर्भर करती हैं)। सेड्रिक बीस्ट बताती है कि टेस्टगंज में परीक्षणों के निष्पादन के क्रम में यह कैसे करना है ।


14
या तो आपके पास दो स्वतंत्र परीक्षण हैं, या आपके पास केवल एक परीक्षण है और इस तरह से कोड होना चाहिए।
जॉन फ्रीडमैन

2
@JonFreedman, जैसा कि मैं इस प्रश्न को समझता हूं, यह परीक्षणों के अन्योन्याश्रित होने का मामला नहीं है, केवल परीक्षण करने के लिए चीजों की कल्पना करने और परिणामों को उस क्रम में प्रकट करने की इच्छा है।
जॉन ब्राइट

174
मैं समझ सकता हूं कि यूनिट परीक्षणों के लिए आदेश लागू नहीं किया जा सकता है, हालांकि एकीकरण परीक्षण लिखने के लिए JUnit का उपयोग करते समय यह अच्छा होगा कि परीक्षण चलाने के आदेश को निर्दिष्ट करने में सक्षम हो। जैसे पहले लॉगइन टेस्ट चलाएं।
ब्रायन डिकासा

13
@BrianD। लॉगिन संभवतः एक परीक्षण के बजाय एक "स्थिरता" है जो अन्य सभी से पहले चलना चाहिए। मैं शायद एक पहले से ही लिखता हूं कि लॉग इन करता हूं और फिर किसी भी क्रम में निष्पादित करने के लिए परीक्षण लिखता हूं।
मार्कोस्पेरेरा

47
निहितार्थ "परीक्षण स्वतंत्र होना चाहिए => परीक्षण स्वतंत्र होना चाहिए" सच नहीं है। छात्र के होमवर्क की स्वचालित ग्रेडिंग पर विचार करें। मैं पहले छोटे इनपुट के लिए और बाद में बड़े इनपुट के लिए उनके समाधान का परीक्षण करना चाहता हूं। जब छोटे इनपुट (समय / मेमोरी सीमा) के लिए समाधान विफल हो रहा है, तो बड़े इनपुट के लिए परीक्षण क्यों चलना चाहिए?
मिरलोन

96

यदि आप जूनिट के अपने मौजूदा उदाहरण से छुटकारा पा लेते हैं, और बिल्ड पथ में JUnit 4.11 या उससे अधिक डाउनलोड करते हैं, तो निम्न कोड उनके नाम के क्रम में परीक्षण विधियों को निष्पादित करेगा, आरोही क्रम में क्रमबद्ध:

@FixMethodOrder(MethodSorters.NAME_ASCENDING)
public class SampleTest {

    @Test
    public void testAcreate() {
        System.out.println("first");
    }
    @Test
    public void testBupdate() {
        System.out.println("second");
    }
    @Test
    public void testCdelete() {
        System.out.println("third");
    }
}

8
हमने वास्तव में एक समान विधि की कोशिश की है test_001_login (), उदाहरण के लिए, लेकिन हालांकि यह ज्यादातर ऑर्डर को संरक्षित करने के लिए काम करता है, इसकी गारंटी नहीं है- हमारे पास प्रति परीक्षण चलाने के कई उदाहरण हैं जहां 004, 005 और 006 007 के बाद चलाए जाते हैं। आप कहते हैं, "WTF !," और जवाब के लिए StackOverflow के लिए चलाते हैं।
मैक्स पी मागे

बहुत बढ़िया - JUnit 4.12 में उपलब्ध
DtechNet

1
मेरे परीक्षणों में: testAcase - काम किया, test_A_case / testA_case - नहीं किया!
रोडिस्लाव मोल्दोवन

6
मैंने इस एनोटेशन पैरामीटर "MethodSorters.JVM" की कोशिश की है, उदाहरण के लिए "@FixMethodOrder (MethodSorters.JVM)"। एपीआई से: जेवीएम - जेवीएम द्वारा लौटाए गए क्रम में परीक्षण विधियों को छोड़ देता है। मेरे द्वारा किए जा रहे काम (CRUD) के लिए बस ठीक काम करता है, उनके लिखे हुए क्रम में परीक्षण विधियाँ चलाता है। +1
Edvinauskas

1
यह एनोटेशन वास्तव में एक उत्तर है, लेकिन इसमें यह चेतावनी है कि इसे (जूनिट 4.12 में) परिभाषित नहीं किया गया है @Inheritedऔर इसलिए यह मेरे AbstractTestCaseमूल वर्ग पर अप्रभावी हो जाता है ।
अबवोग

49

यदि आदेश महत्वपूर्ण है, तो आपको आदेश स्वयं बनाना चाहिए।

@Test public void test1() { ... }
@Test public void test2() { test1(); ... }

विशेष रूप से, यदि आवश्यक हो, तो आपको परीक्षण करने के लिए कुछ या सभी संभावित आदेश क्रमपरिवर्तन सूचीबद्ध करने चाहिए।

उदाहरण के लिए,

void test1(); 
void test2(); 
void test3(); 


@Test
public void testOrder1() { test1(); test3(); }

@Test(expected = Exception.class)
public void testOrder2() { test2(); test3(); test1(); }

@Test(expected = NullPointerException.class)
public void testOrder3() { test3(); test1(); test2(); }

या, सभी क्रमपरिवर्तन की पूर्ण परीक्षा:

@Test
public void testAllOrders() {
    for (Object[] sample: permute(1, 2, 3)) {
        for (Object index: sample) {
            switch (((Integer) index).intValue()) {
                case 1: test1(); break; 
                case 2: test2(); break; 
                case 3: test3(); break; 
            }
        }
    }
}

यहाँ, permute()एक सरल कार्य है जो सरणी के संग्रह में सभी संभव क्रमों को पुनरावृत्त करता है।


लेकिन क्या होगा अगर विभिन्न फाइलों में परीक्षण?
ओलेग अब्राहेव

3
पहले कोड ब्लॉक में, फिर सेtest2 चलता है । जूनित पहले भी चल सकता है । यह संभवत: वह नहीं है जो आपने इरादा किया था, और सवाल का एक वैध उत्तर नहीं। test1 test2test1
Toolforger

47

TestNG के लिए प्रवासन सबसे अच्छा तरीका है, लेकिन मैं jUnit के लिए यहां कोई स्पष्ट समाधान नहीं देखता हूं। यहाँ सबसे पठनीय समाधान / स्वरूपण है जो मुझे jUnit के लिए मिला है:

@FixMethodOrder(MethodSorters.NAME_ASCENDING)
public class SampleTest {
    @Test
    void stage1_prepareAndTest(){};

    @Test
    void stage2_checkSomething(){};

    @Test
    void stage2_checkSomethingElse(){};

    @Test
    void stage3_thisDependsOnStage2(){};

    @Test
    void callTimeDoesntMatter(){}
}

यह सुनिश्चित करता है कि स्टेज 2 विधियों के बाद और स्टेज 3 वाले से पहले स्टेज 2 विधियों को बुलाया जाता है।


5
यह दृष्टिकोण अच्छा है, लेकिन यह उल्लेख करना मान्य होगा कि यदि आपके पास 10 से अधिक परीक्षण हैं तो यह ठीक नहीं होगा जब तक कि आप एक 0उपसर्ग नहीं जोड़ते हैं , जैसेvoid stage01_prepareAndTest(){ }
एलियक्स

यदि आपके पास 10 से अधिक चरण हैं (परीक्षण नहीं) - हां। मैं चरणों की संख्या को सीमित करना और प्रत्येक चरण में अधिक परीक्षण करना पसंद करता हूं, जब यह संभव है।
जोरो

18

इसका एक मुख्य मुद्दा जिसका सामना मैंने तब किया जब मैंने जुनित पर काम किया और मैं निम्नलिखित समाधान के साथ आया जो मेरे लिए ठीक काम करता है:

import java.util.ArrayList;
import java.util.Collections;
import java.util.Comparator;
import java.util.List;

import org.junit.runners.BlockJUnit4ClassRunner;
import org.junit.runners.model.FrameworkMethod;
import org.junit.runners.model.InitializationError;

public class OrderedRunner extends BlockJUnit4ClassRunner {

    public OrderedRunner(Class<?> clazz) throws InitializationError {
        super(clazz);
    }

    @Override
    protected List<FrameworkMethod> computeTestMethods() {
        List<FrameworkMethod> list = super.computeTestMethods();
        List<FrameworkMethod> copy = new ArrayList<FrameworkMethod>(list);
        Collections.sort(copy, new Comparator<FrameworkMethod>() {

            @Override
            public int compare(FrameworkMethod f1, FrameworkMethod f2) {
                Order o1 = f1.getAnnotation(Order.class);
                Order o2 = f2.getAnnotation(Order.class);

                if (o1 == null || o2 == null) {
                    return -1;
                }

                return o1.order() - o2.order();
            }
        });
        return copy;
    }
}

नीचे एक इंटरफ़ेस भी बनाएं:

 @Retention(RetentionPolicy.RUNTIME)


@Target({ ElementType.METHOD})

public @interface Order {
public int order();
}

अब मान लीजिए कि आपके पास ए श्रेणी है, जहाँ आपने नीचे कई परीक्षण मामले लिखे हैं:

(@runWith=OrderRunner.class)
Class A{
@Test
@Order(order = 1)

void method(){

//do something

}

}

इसलिए निष्पादन "विधि ()" नामक विधि से शुरू होगा। धन्यवाद!


संस्करण 1.6.0 के बाद से PowerMock के साथ एक और JUnit धावक का उपयोग करना। PowerMock के पास JUnit नियम का उपयोग किए बिना किसी अन्य JUnit धावक को परीक्षण निष्पादन का समर्थन करने के लिए समर्थन है। यह आपकी पसंद के किसी अन्य धावक के लिए वास्तविक परीक्षण-निष्पादन को छोड़ देता है। @RunWith(PowerMockRunner.class) @PowerMockRunnerDelegate(OrderedRunner.class)
Kyriakos Georgiopoulos

11

वर्तमान में JUnit वर्ग एनोटेशन का उपयोग करके परीक्षण विधियों को चलाने की अनुमति देता है:

@FixMethodOrder(MethodSorters.NAME_ASCENDING)
@FixMethodOrder(MethodSorters.JVM)
@FixMethodOrder(MethodSorters.DEFAULT)

डिफ़ॉल्ट रूप से परीक्षण विधियाँ वर्णमाला क्रम में चलाई जाती हैं। इसलिए, विशिष्ट विधियों के क्रम को सेट करने के लिए आप उन्हें इस तरह नाम दे सकते हैं:

a_TestWorkUnit_WithCertainState_ShouldDoSomething b_TestWorkUnit_WithCertainState_ShouldDoSomething c_TestWorkUnit_WithCertainState_ShouldDoSomething

आप यहां उदाहरण पा सकते हैं ।


8

(जैसा कि अभी तक अप्रकाशित) परिवर्तन https://github.com/junit-team/junit/pull/386 एक परिचय देता है @SortMethodsWithhttps://github.com/junit-team/junit/pull/293 ने कम से कम आदेश को उसके बिना अनुमानित किया (जावा 7 में यह काफी यादृच्छिक हो सकता है)।


1
ऐसा लगता है कि # 386 का 4.11 में विलय कर दिया गया है।
जेसी ग्लिक

जैसा कि इस पृष्ठ के नीचे उल्लेख किया गया है, यह वास्तव में 4.11 में @FixMethodOrderनहीं कहा जाता है@SortMethodsWith
21

6

एक JUnit रिपोर्ट को देखें। JUnit पहले से ही पैकेज द्वारा आयोजित किया जाता है। प्रत्येक पैकेज में TestSuite कक्षाएं होती हैं (या हो सकती हैं), जिनमें से प्रत्येक में कई TestCases चलते हैं। प्रत्येक TestCase में प्रपत्र के कई परीक्षण विधियाँ हो सकती हैं public void test*(), जिनमें से प्रत्येक वास्तव में TestCase वर्ग का एक उदाहरण बन जाएगा जिससे वे संबंधित हैं। प्रत्येक परीक्षण विधि (TestCase उदाहरण) में एक नाम और एक पास / असफल मानदंड है।

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

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

TestCase विधियाँ TestCase के चरण थे, और परीक्षण डिजाइनरों को प्रति परीक्षण चरण में एक अलग पास / असफल मानदंड मिला। अब परीक्षण के कदम उछल गए हैं, और परीक्षण (निश्चित रूप से) विफल हो गए हैं।

उदाहरण के लिए:

Class testStateChanges extends TestCase

public void testCreateObjectPlacesTheObjectInStateA()
public void testTransitionToStateBAndValidateStateB()
public void testTransitionToStateCAndValidateStateC()
public void testTryToDeleteObjectinStateCAndValidateObjectStillExists()
public void testTransitionToStateAAndValidateStateA()
public void testDeleteObjectInStateAAndObjectDoesNotExist()
public void cleanupIfAnythingWentWrong()

प्रत्येक परीक्षण विधि का दावा है और अपनी अलग पास / असफल मानदंडों की रिपोर्ट करता है। JUnit सारांश रिपोर्ट में प्रत्येक "चरण" के पास / असफल मानदंड की ग्रैन्युलैरिटी को खो देने के लिए इसे "एक बड़ी परीक्षा विधि" में बदलना। ... और वह मेरे प्रबंधकों को परेशान करता है। वे वर्तमान में एक और विकल्प की मांग कर रहे हैं।

क्या कोई समझा सकता है कि स्क्रैम्ब्ल्ड टेस्ट मेथड ऑर्डर के साथ एक JUnit प्रत्येक क्रमिक परीक्षण चरण के अलग-अलग पास / असफल मानदंड का समर्थन करेगा, जैसा कि ऊपर और मेरे प्रबंधन द्वारा आवश्यक है?

प्रलेखन के बावजूद, मैं इसे JUnit ढांचे में एक गंभीर प्रतिगमन के रूप में देखता हूं जो बहुत सारे परीक्षण डेवलपर्स के लिए जीवन को मुश्किल बना रहा है।


6

JUnit 5 अपडेट (और मेरी राय)

मुझे लगता है कि यह JUnit के लिए काफी महत्वपूर्ण विशेषता है, अगर JUnit के लेखक ऑर्डर सुविधा नहीं चाहते हैं, तो क्यों?

डिफ़ॉल्ट रूप से, इकाई परीक्षण लाइब्रेरी स्रोत फ़ाइल में होने वाले क्रम में परीक्षण निष्पादित करने का प्रयास नहीं करती है।
JUnit 5 के रूप में JUnit 4 उस तरह से काम करता है। क्यों ? क्योंकि यदि आदेश मायने रखता है तो इसका मतलब है कि कुछ परीक्षण उनके बीच युग्मित हैं और यह इकाई परीक्षणों के लिए अवांछनीय है
तो @NestedJUnit 5 द्वारा पेश की गई सुविधा उसी डिफ़ॉल्ट दृष्टिकोण का अनुसरण करती है।

लेकिन एकीकरण परीक्षणों के लिए, परीक्षण पद्धति का क्रम मायने रख सकता है क्योंकि एक परीक्षण विधि एक अन्य परीक्षण विधि द्वारा अपेक्षित तरीके से आवेदन की स्थिति को बदल सकती है। उदाहरण के लिए जब आप ई-शॉप चेकआउट प्रसंस्करण के लिए एकीकरण परीक्षण लिखते हैं, तो निष्पादित की जाने वाली पहली परीक्षा विधि एक ग्राहक को पंजीकृत कर रही है, दूसरा टोकरी में आइटम जोड़ रहा है और अंतिम चेकआउट कर रहा है। यदि परीक्षण धावक उस आदेश का सम्मान नहीं करता है, तो परीक्षण परिदृश्य त्रुटिपूर्ण है और विफल हो जाएगा।
तो JUnit 5 में (5.4 संस्करण से) आपके पास परीक्षण के वर्ग को एनोटेट @TestMethodOrder(OrderAnnotation.class)करके और ऑर्डर @Order(numericOrderValue)के तरीकों के लिए आदेश को निर्दिष्ट करके निष्पादन आदेश को निर्धारित करने की सभी समान संभावना है।

उदाहरण के लिए :

@TestMethodOrder(OrderAnnotation.class) 
class FooTest {

    @Order(3)
    @Test
    void checkoutOrder() {
        System.out.println("checkoutOrder");
    }

    @Order(2)
    @Test
    void addItemsInBasket() {
        System.out.println("addItemsInBasket");
    }

    @Order(1)
    @Test
    void createUserAndLogin() {
        System.out.println("createUserAndLogin");
    }
}

आउटपुट:

createUserAndLogin

addItemsInBasket

checkoutOrder

वैसे, निर्दिष्ट करने @TestMethodOrder(OrderAnnotation.class)की आवश्यकता नहीं है (कम से कम 5.4.0 संस्करण मैंने परीक्षण किया है)।

साइड नोट
प्रश्न के बारे में: एकीकरण टेस्ट लिखने के लिए JUnit 5 सबसे अच्छा विकल्प है? मुझे नहीं लगता है कि यह विचार करने वाला पहला उपकरण होना चाहिए (ककड़ी और सह अक्सर एकीकरण परीक्षणों के लिए अधिक विशिष्ट मूल्य और सुविधाएँ ला सकते हैं) लेकिन कुछ एकीकरण परीक्षण मामलों में, जेयूनिट ढांचा पर्याप्त है। तो यह एक अच्छी खबर है कि यह सुविधा मौजूद है।


4

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


3

जब आप चाहते हैं पूरी तरह से उचित है जब परीक्षण मामलों को एक सूट के रूप में चलाया जा रहा है।

दुर्भाग्य से अभी पूर्ण समाधान देने का समय नहीं है, लेकिन कक्षा पर एक नज़र डालें:

org.junit.runners.Suite

जो आपको एक विशिष्ट क्रम में परीक्षण मामलों (किसी भी परीक्षण वर्ग से) को कॉल करने की अनुमति देता है।

इनका उपयोग कार्यात्मक, एकीकरण या सिस्टम परीक्षण बनाने के लिए किया जा सकता है।

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

हम यूनिट, एकीकरण और सिस्टम परीक्षणों, कभी-कभी डेटा संचालित, कभी-कभी प्रतिबद्ध, और कभी-कभी एक सूट के रूप में चलाते हैं, के लिए एक ही कोड का पुन: उपयोग / वारिस करते हैं।


2
क्या आपके पास 2014 से इस उत्तर को पूरा करने का समय नहीं है? ;)
चार्ली

2

मेरा समाधान यहां देखें: "जूनित और जावा 7."

इस लेख में मैं वर्णन करता हूं कि कैसे जूनियर परीक्षण को क्रम में चलाना है - "जैसा कि आपके स्रोत कोड में"। टेस्ट चलाए जाएंगे, क्योंकि आपके टेस्ट तरीके क्लास फाइल में दिखाई देते हैं।

http://intellijava.blogspot.com/2012/05/junit-and-java-7.html

लेकिन जैसा पास्कल थिवेंट ने कहा, यह अच्छा अभ्यास नहीं है।


मैंने आपका ब्लॉग पोस्ट (रूसी में!) देखा था, लेकिन यह बहुत जटिल है।
निकोलस बारबुल्सको

1
@ नाइकोलाबार्बुल्सको मेरे दो ब्लॉग (rus और eng) हैं। यह बहुत जटिल है, क्योंकि आप निष्पादन आदेश निर्भरता के साथ परीक्षण नहीं बनाते हैं। मेरा समाधान समाधान है, लेकिन वास्तविक समाधान - उस निर्भरता को दूर करना है।
kornero

1
इस पोस्ट में वास्तविक उत्तर नहीं है। कृपया, लिंक के अलावा कम से कम मूल स्पष्टीकरण जोड़ने पर विचार करें।
डिफ़ॉल्ट लोकेल

1

5.4 के साथ, आप ऑर्डर निर्दिष्ट कर सकते हैं:

@Test
@Order(2)
public void sendEmailTestGmail() throws MessagingException {

आपको बस अपनी कक्षा को एनोटेट करने की आवश्यकता है

@TestMethodOrder(OrderAnnotation.class)

https://junit.org/junit5/docs/current/user-guide/#writing-tests-test-execution-order

मैं अपने प्रोजेक्ट में इसका उपयोग कर रहा हूँ और यह बहुत अच्छी तरह से काम करता है!


0

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

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

test12 test2 से पहले चलेगा

इसलिए:

testA_MyFirstTest testC_ThirdTest testB_ATestThatRunsSecond


0

: कृपया इस एक बाहर की जाँच https://github.com/TransparentMarket/junit । यह परीक्षण को उस क्रम में चलाता है जिसे वे निर्दिष्ट करते हैं (संकलित वर्ग फ़ाइल के भीतर परिभाषित)। इसके अलावा इसमें सब पैकेज द्वारा परिभाषित परीक्षणों को चलाने के लिए एक ऑलस्टेस सूट की सुविधा है। AllTests कार्यान्वयन का उपयोग करके गुणों के लिए फ़िल्टरिंग में समाधान का विस्तार किया जा सकता है (हम @ फ़ॉस्ट एनोटेशन का उपयोग करते थे, लेकिन वे अभी तक प्रकाशित नहीं हुए थे)।


0

यहाँ JUnit का एक विस्तार है जो वांछित व्यवहार उत्पन्न कर सकता है: https://github.com/aafuks/aaf-junit

मुझे पता है कि यह JUnit दर्शन के लेखकों के खिलाफ है, लेकिन जब वातावरण में JUnit का उपयोग किया जाता है जो कि सख्त इकाई परीक्षण नहीं हैं (जैसा कि जावा में अभ्यास किया गया है) यह बहुत मददगार हो सकता है।


0

मैंने यह सोचकर यहाँ समाप्त किया कि मेरे परीक्षण क्रम में नहीं चल रहे थे, लेकिन सच्चाई यह है कि गड़बड़ मेरे async नौकरियों में थी। जब संगामिति के साथ काम करते हैं तो आपको अपने परीक्षणों के बीच भी संगणना जाँच करने की आवश्यकता होती है। मेरे मामले में, नौकरी और परीक्षण एक सेमाफोर साझा करते हैं, इसलिए अगले परीक्षण लटकाए जाते हैं जब तक कि रनिंग जॉब लॉक जारी नहीं करता है।

मुझे पता है कि यह पूरी तरह से इस सवाल से संबंधित नहीं है, लेकिन शायद सही मुद्दे को लक्षित करने में मदद कर सकता है


0

आप इनमें से किसी एक कोड का उपयोग कर सकते हैं:

@FixMethodOrder(MethodSorters.JVM)OR `@FixMethodOrder(MethodSorters.DEFAULT)` OR `@FixMethodOrder(MethodSorters.NAME_ASCENDING)` before your test class like this:


@FixMethodOrder(MethodSorters.NAME_ASCENDING)


public class BookTest { ...}
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.