2010-08-26 9 views
48

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

ShopSystem शायद मेरे मुख्य प्रोजेक्ट का नाम - क्या मुझे कहें, ShopSystemTest नामक एक प्रोजेक्ट बनाना चाहिए?

सामान्य रूप से - मुख्य परियोजना फ़ोल्डर से परीक्षण कोड कितना दूर "दूर" होना चाहिए? यदि मैं मुख्य प्रोजेक्ट के भीतर परीक्षण कोड संग्रहीत करता हूं और फिर मुख्य प्रोजेक्ट को एक रननेबल जार के रूप में निर्यात करता हूं तो यह परीक्षण कोड ले जाएगा, जो आदर्श नहीं है ...

सुझाव?

उत्तर

59

हालांकि कोई भी सही तरीका नहीं है, सामान्य दृष्टिकोण एक ही परियोजना में यूनिट परीक्षण रखना है।

आप एक दूसरा स्रोत फ़ोल्डर (जैसे test) बना सकते हैं, जहां आप परीक्षण के तहत कक्षाओं के रूप में अपनी परीक्षा कक्षाओं को उसी पैकेज में डालते हैं। यह परीक्षण कक्षाओं के साथ आपके मुख्य स्रोत पैकेजों को बाढ़ न होने पर पैकेज-निजी कक्षाओं का परीक्षण करने की अनुमति देता है।

आपका स्रोत फ़ोल्डर/पैकेज संरचना तो इस प्रकार दिखाई देगा:

-sources 
    -main 
     -my.package 
      -MyClass.java 
    -test 
     -my.package 
      -MyClassTest.java 

तब आप अपने निर्माण कॉन्फ़िगर test स्रोत फ़ोल्डर शामिल नहीं जब जार पैकिंग कर सकते हैं।

4

आमतौर पर आप है -

/src/main/java (for codes) 

/src/test/java (for tests) 
3

पर विचार करें Maven तरीका: इस तरह से

src 
|--main 
|  |--java 
|--test 
     |--java 

आपका स्रोत कोड src/मुख्य/जावा में चला जाता है एक Maven परियोजना में, soruces आयोजन किया जाता है, अपने JUnit परीक्षण कोड src/test/java में जाता है, वे दोनों स्रोत फ़ोल्डर होते हैं (और परिणामस्वरूप आप अपने जावा कोड के समान पैकेज में अपना जुनीट कोड डाल सकते हैं, लेकिन एक अलग स्रोत फ़ोल्डर में)।

ब्याज यह है कि सामान्य कोडिंग के लिए, आपके जुनीट कक्षा कोड पैकेज में हैं, लेकिन जार निर्माण पर, आप केवल स्रोत/मुख्य/जावा से आने वाले वर्ग ले सकते हैं और अपने परीक्षण जारी नहीं कर सकते हैं।

19

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

project 
    src 
     main 
      java  // source files 
      resources // xml, properties etc 
     test 
      java  // source files 
      resources // xml, properties etc 

और ग्रहण में, जब आप new -> JUnit test case चुनते हैं, तो आप सिर्फ src/परीक्षण/जावा के लिए स्रोत फ़ोल्डर बदलने और सुझाव पैकेज छोड़ है।

(समान पैकेज में शेष की रक्षा की और पैकेज scoped सदस्यों के लिए उपयोग कर रहा है के लाभों में से एक है, हालांकि यह नहीं है 'उचित' इकाई परीक्षण व्यवहार)


अद्यतन: यहाँ कुछ कोड है

मुख्य वर्ग (src/मुख्य/जावा में): मेरा आखिरी बिंदु को वर्णन

package com.test; 
public class Foo{ 

    static class Phleem{ 
     public Phleem(final String stupidParameter){ 
     } 
    } 

    String bar; 
    protected String baz; 
    protected Object thingy; 

} 

टेस्ट वर्ग (एसआर में सी/परीक्षण/जावा):

package com.test; 
import org.junit.Test; 

public class FooTest{ 

    @Test 
    public void testFoo(){ 
     final Foo foo = new Foo(); 
     foo.bar = "I can access default-scoped members"; 
     foo.baz = "And protected members, too"; 
     foo.thingy = new Foo.Phleem("And I can access default-scoped classes"); 
    } 

} 
+0

"संरक्षित और पैकेज स्कॉप्ड सदस्यों तक पहुंच" - संरक्षित सदस्यों तक पहुंच के लिए, आपको कक्षा के तहत कक्षा के अधीन होना होगा। आपका मतलब क्या है पैकेज-स्कोप्ड कक्षाओं तक पहुंचने में सक्षम है, है ना? – Henning

+0

ओह, और सदस्य भी, निश्चित रूप से आप सही हैं। मैंने डिफॉल्ट-स्कोप्ड सदस्यों का उपयोग शायद ही कभी किया है कि कभी-कभी मैं भूल जाता हूं कि वे मौजूद हैं। – Henning

+0

ओच! मुझे एक ही पैकेज में अन्य कक्षाओं से 'सुरक्षित' अनुमति की अनुमति नहीं थी। ठीक है, यह चीज़ों को साफ़ करता है, धन्यवाद। – Henning

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