2015-12-24 8 views
9

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

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

मैं उस क्रम में केवल "खराब सेटअप" और "खराब सेटअप के बाद विफल होने" परीक्षण कैसे चला सकता हूं?

+0

आप परीक्षण –

+2

@Lashane मैं * पता करने के लिए * समस्या परीक्षण को ठीक करने की जरूरत है ठीक करना चाहिए। यह सवाल यह जानने के बारे में है कि समस्या क्या है। –

+0

आमतौर पर "डिबगिंग" इसे हल करने का तरीका है, सभी परीक्षण चलाएं, यह पता लगाएं कि यह कहां विफल हो गया है, इससे पहले ब्रेकपॉइंट डालें - पता लगाएं कि यह वास्तव में क्यों विफल रहता है, यह किस स्थिति/चर को ले जाता है, यह पता चलता है कि यह राज्य कहां बदल गया है, ब्रेकपॉइंट्स डालें और सभी परीक्षणों को फिर से चलाएं –

उत्तर

20

JUnit's wiki के अनुसार:

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

संस्करण 4.11 से, जुनीट डिफ़ॉल्ट रूप से एक निर्धारिती का उपयोग करेगा, लेकिन अनुमानित, आदेश (MethodSorters.DEFAULT) नहीं। बदलने के लिए परीक्षण निष्पादन आदेश बस @FixMethodOrder का उपयोग कर अपने परीक्षण वर्ग व्याख्या और उपलब्ध MethodSorters में से एक निर्दिष्ट करें:

@FixMethodOrder(MethodSorters.JVM): आदेश JVM द्वारा लौटे में परीक्षण तरीकों निकलने वाला है। यह आदेश रन से चलाने के लिए भिन्न हो सकता है।

@FixMethodOrder(MethodSorters.NAME_ASCENDING): लेक्सिकोग्राफिक ऑर्डर में विधि नाम से परीक्षण विधियों टाइप करें।

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

+0

कूल, यह सहायक है। अंत में, मैंने मैन्युअल रूप से सब कुछ (अस्थायी रूप से) –

+0

ओहम्मम, अच्छा हैक :) –

+0

@FixMethodOrder (MethodSorters.NAME_ASCENDING) पर मैन्युअल रूप से @ इग्नोर डाल दिया है। –

0

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

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

4

के रूप में अली Dehghani से कहा, तुम से

@FixMethodOrder (MethodSorters.NAME_ASCENDING) परीक्षा पद्धति निष्पादन आदेश कर सकते हैं: परीक्षण तरीकों विधि नाम से प्रकार कोषगत क्रम में।

कोड:

@FixMethodOrder(MethodSorters.NAME_ASCENDING) 
public class ApplicationTest extends ActivityInstrumentationTestCase2<MainActivity> { 

    public ApplicationTest() { 
     super(MainActivity.class); 
    } 

    @Rule 
    public ActivityTestRule<MainActivity> mActivityTestRule = new ActivityTestRule<>(MainActivity.class); 

    @Test 
    void t1AttachUI(){ 
     // testing code goes here 
    } 

    @Test 
    void t2InitializeViews(){ 
     // testing code goes here 
    }; 

    @Test 
    void t3SettingValues(){ 
     // testing code goes here 
    }; 

    @Test 
    void t4Validation(){ 
     // testing code goes here 
    }; 

    @Test 
    void t3AfterButtonPress(){ 
     // testing code goes here 
    }; 
} 
+2

यह इस परिदृश्य में मदद नहीं करता है क्योंकि यह समस्या कई वर्गों को फैलाती है। –

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