जुनीट - क्या मुझे टियरडाउन में संसाधनों को शून्य करना चाहिए जो सेटअप में तत्काल थे?

Question

मैं अब जुनीट के बारे में एक पुस्तक पढ़ रहा हूं और लेखक टीयरडाउन विधि में संसाधनों को कम करने की सलाह देते हैं। क्यूं कर? क्या यह जीसी का काम नहीं है? क्या यह गंभीर रूप से कोई नुकसान पहुंचा सकता है?

public class SomeTest extends TestCase { 
    Vector vector; 
    List<Object> list; 

    protected void setUp() { 
    vector = new Vector(); 
    list = new ArrayList<Object>(); 
    } 

    // messing with resources 
    // adding, deleting, testing whatever 

    protected void tearDown() { 
    vector = null; 
    list = null; 
    } 
} 

आपको क्या लगता है:

इस तरह उदाहरण के थिंक चलें? क्या वह कोड आंसू में आवश्यक है?

Answer 1

हां, यह वास्तव में आवश्यक हो सकता है।

तुम देखो, JUnit वास्तव में प्रत्येक परीक्षा पद्धति के लिए Test वर्ग का एक अलग इंस्टेंस पैदा करेगा, और जब तक पूरे टेस्ट स्वीट समाप्त हो गया है Junit3 परीक्षण धावक (JUnit4 के साथ ऐसा नहीं है) के आसपास इन उदाहरणों रखेंगे।

इसलिए, यदि आपकी (JUnit3) टेस्ट क्लास में ऐसे फ़ील्ड हैं जो बहुत मेमोरी लेते हैं, तो आपके पास बड़ी संख्या में टेस्ट विधियां होने पर आसानी से ढेर स्थान से बाहर निकल सकते हैं। बेशक, यदि आपके उदाहरण कोड में उन संग्रहों में केवल कुछ हद तक छोटे तार होते हैं, इससे कोई फर्क नहीं पड़ता।

Answer 2

यह निर्भर करता है कि आप संसाधन पर विचार करते हैं। जबकि ढेर अंतरिक्ष एक संसाधन है, आप संभवतया आपके बाद (वाईएमएमवी) के बाद जीसी सफाई से दूर हो सकते हैं।

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

मुझे एक बार एक स्थिति थी कि कुछ हाइबरनेट कोड के लिए एकीकरण परीक्षण ठीक से साफ नहीं हुआ और इसके परिणामस्वरूप कुछ वास्तव में अजीब त्रुटियां हुईं। मुझे इतनी बुरी तरह खोजने और नाराज करने में कई घंटे लग गए कि मैं कभी भी वही गलती नहीं करूंगा।

Answer 3

जुनीट 4.x शैली परीक्षण और परीक्षण सूट JUnit 3.x परीक्षण सूट से अलग तरीके से संभालते हैं।

टी एल; डॉ: आप JUnit3 शैली परीक्षण में शून्य पर खेतों स्थापित करना चाहिए लेकिन आप JUnit4 शैली परीक्षण में की जरूरत नहीं है।

JUnit 3.x शैली परीक्षण के साथ

, एक TestSuite अन्य Test वस्तुओं के लिए संदर्भ (TestCase वस्तुओं या अन्य TestSuite वस्तुओं हो सकता है) शामिल हैं। यदि आप कई परीक्षणों के साथ एक सूट बनाते हैं, तो बाहरीतम सूट के पूरे भाग के लिए सभी पत्ते TestCase ऑब्जेक्ट्स के लिए कठिन संदर्भ होंगे। यदि आपकी कुछ टेस्टकेस ऑब्जेक्ट्स setUp() में ऑब्जेक्ट आवंटित करती हैं जो बहुत सारी मेमोरी लेती हैं, और उन ऑब्जेक्ट्स के संदर्भ उन क्षेत्रों में संग्रहीत हैं जो null पर tearDown() में सेट नहीं हैं, तो आपके पास स्मृति समस्या हो सकती है।

दूसरे शब्दों में, जुनीट 3.x शैली परीक्षणों के लिए, वास्तविक परीक्षण TestCase ऑब्जेक्ट्स को संदर्भित करने के लिए परीक्षणों का विनिर्देश। TestCase ऑब्जेक्ट से पहुंचने योग्य किसी ऑब्जेक्ट को परीक्षण चलाने के दौरान स्मृति में रखा जाएगा।

जुनीट 4.x शैली परीक्षणों के लिए, कौन से परीक्षण चलाने के लिए Description ऑब्जेक्ट्स का उपयोग करता है। Description ऑब्जेक्ट एक मान ऑब्जेक्ट है जो निर्दिष्ट करता है कि क्या चलाना है, लेकिन इसे कैसे चलाया जाए। परीक्षण Runner ऑब्जेक्ट द्वारा चलाए जाते हैं जो परीक्षण या सूट के Description लेते हैं और यह निर्धारित करता है कि परीक्षण कैसे निष्पादित किया जाए।परीक्षण श्रोता को परीक्षण की स्थिति की अधिसूचना भी Description वस्तुओं का उपयोग करती है।

JUnit4 परीक्षण मामलों के लिए डिफ़ॉल्ट धावक, JUnit4, चारों ओर केवल कि परीक्षण की रन की अवधि के लिए परीक्षण वस्तु के लिए एक संदर्भ रहता है। यदि आप एक कस्टम धावक (@RunWith एनोटेशन के माध्यम से) का उपयोग करते हैं, तो वह धावक लंबे समय तक परीक्षणों के संदर्भों को संदर्भित रख सकता है या नहीं।

शायद आप सोच रहे हैं कि क्या होता है यदि आप JUnit4-style Suite में जुनीट 3-शैली परीक्षण कक्षा शामिल करते हैं? JUnit4 new TestSuite(Class) पर कॉल करेगा जो एक परीक्षण TestCase प्रति परीक्षण विधि उदाहरण देगा। धावक परीक्षण चलाने के पूरे जीवन के लिए TestSuite का संदर्भ रखेगा।

संक्षेप में, यदि आप JUnit4 शैली परीक्षण लिख रहे हैं, एक आंसू नीचे में null के लिए अपने परीक्षण मामले के क्षेत्रों की स्थापना (निश्चित रूप से करते हैं, मुक्त संसाधनों) के बारे में चिंता मत करो। यदि आप JUnit3-style परीक्षण लिख रहे हैं जो setUp() में बड़ी ऑब्जेक्ट्स आवंटित करते हैं और TestCase के फ़ील्ड में उन ऑब्जेक्ट्स को स्टोर करते हैं, तो फ़ील्ड को null पर सेट करने पर विचार करें।