2009-10-08 15 views
58

जावा कोड के लिए यूनिट परीक्षणों का एक सूट बनाते समय, स्रोत कोड के संबंध में परीक्षण कोड कहां रखा जाए, इसके लिए एक सम्मेलन है?जावा यूनिट परीक्षण, निर्देशिका लेआउट

उदाहरण के लिए, अगर मैं एक निर्देशिका /java कि .java स्रोत फ़ाइलों का एक गुच्छा शामिल है, यह बेहतर ही /java में परीक्षण मामलों डाल या /java/test की तरह कुछ का उपयोग करने के लिए है।

यदि उत्तरार्द्ध को प्राथमिकता दी जाती है, तो आप कोड के आंतरिक परीक्षणों का परीक्षण कैसे करते हैं जब private/protected कक्षा के सदस्य पैकेज के बाहर उपलब्ध नहीं हैं?

उत्तर

56

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

PROJECT_ROOT 
    +--- src/ 
    +----test/ 

आप src के तहत एक वर्ग com.foo.MyClass घोषणा कर सकते हैं और इसके परीक्षण com.foo.MyClassTest के तहत test

निजी सदस्यों के लिए उपयोग के रूप में, आप विधियां प्रारंभ करने (Class.getDeclaredMethod.setAccessible के माध्यम से अपने पहुंच फेरबदल) प्रतिबिंब उपयोग कर सकते हैं, या आप स्रोत कोड पर ही कुछ टिप्पणी पर ही आधारित परीक्षण डाल करने के लिए TestNG/junit5 की तरह कुछ इस्तेमाल कर सकते हैं (मुझे व्यक्तिगत रूप से लगता है कि यह एक बुरा विचार है)।

क्यों java.net पर कुछ परियोजनाओं की जाँच नहीं देखना चाहते हैं कि वे संगठित बातें है, उदाहरण के swinglabs के लिए (SVN भंडार कर रहा हूँ डर बहुत धीमी है मैं)?

+0

'test' में स्रोत भी शामिल है ... यह भी कि' src' मेवेन दुनिया से आया –

9

अधिकांश समय इस तरह से किया जाता है:

<SOME_DIR>/project/src/com/foo/Application.java 
<SOME_DIR>/project/test/com/foo/ApplicationTest.java 

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

आप निजी सामान का परीक्षण नहीं कर सकते हैं, जब तक कि इसे कक्षा में स्वयं घोषित न किया जाए।

वितरण करने पर, आप सिर्फ .class src द्वारा उत्पन्न, नहीं परीक्षण

+0

क्यों न केवल 'स्रोत' का उपयोग करें? 'संसाधन'' होने पर 'src' क्यों ... –

+0

परीक्षण src फ़ोल्डर में होना चाहिए। https://maven.apache.org/guides/introduction/introduction-to-the- मानक- निर्देशिका-layout.html –

79

मैं Apache Software Foundation's standard directory structure है, जो इस पैदावार पालन करने की सलाह पैक:

module/ 
    src/ 
    main/ 
     java/ 
    test/ 
     java/ 

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

यह संरचना इकाई परीक्षणों को परीक्षण और संरक्षित स्तर की जांच करने की अनुमति देती है परीक्षण के तहत इकाइयों के तरीकों, मानते हुए कि आप अपने परीक्षण मामलों को उसी पैकेज में रखते हैं जो वे परीक्षण करते हैं। निजी तरीकों का परीक्षण करने के संबंध में - मैं परेशान नहीं होगा। कुछ और, सार्वजनिक, पैकेज, या संरक्षित उन्हें कॉल करता है और आप उन चीजों का परीक्षण करने के लिए पूर्ण परीक्षण कवरेज प्राप्त करने में सक्षम होना चाहिए।

वैसे, ऊपर दिया गया लिंक मैवेन, अपाचे का मानक निर्माण उपकरण है। प्रत्येक जावा प्रोजेक्ट में वे इस मानक के अनुरूप हैं, साथ ही साथ जिन परियोजनाओं का सामना मैंने किया है, वे मेवेन के साथ बनाया गया है।

+5

+1 यदि आप मेवेन का उपयोग नहीं करते हैं, तो भी इस लेआउट का पालन करना एक अच्छा विचार है (एक प्रकार उद्योग के सर्वोत्तम अभ्यासों के आधार पर वास्तविक तथ्य का)। –

+6

मेवेन का एकमात्र कारण यहां उल्लेख किया गया है क्योंकि इसकी वेबसाइट एक ऐसी जगह है जहां अपाचे मानक निर्देशिका लेआउट दस्तावेज किया गया है। इसके बारे में आपकी पसंद या नापसंद इस संबंध में अप्रासंगिक है कि प्रश्न में निर्देशिका संरचना एक अच्छी है या नहीं। शायद आप उस उत्तर पर टिप्पणी कर सकते हैं जो आपकी राय के साथ संरेखित करता है यह इंगित करने के लिए कि निर्देशिका संरचना बेहतर क्यों है। – SingleShot

+0

मैं इस सिफारिश का पालन नहीं करना चाहूंगा क्योंकि आप सिर्फ "src" फ़ोल्डर को जार/युद्ध में निर्यात नहीं कर सकते हैं। आपको परीक्षण पैकेज को स्पष्ट रूप से बहिष्कृत करना होगा और परीक्षण पैकेज के तहत संपूर्ण पैकेज संरचना का पुनर्निर्माण करना होगा। – guerda

5

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

तो अगर मैं एक परियोजना 'मेरी परियोजना' मैं भी 'मेरे परियोजना परीक्षण', बनाने के तो मैं निम्नलिखित निर्देशिका संरचना है है:

my-project 
    +--- src/com/foo 
my-project-test 
    +---test/com/foo 

यह दृष्टिकोण सुनिश्चित करता है कि परीक्षण कोड निर्भरता नहीं है प्रदूषण उत्पादन कोड।

मेरी व्यक्तिगत राय में पैकेज निजी और संरक्षित तरीकों का परीक्षण किया जाना चाहिए साथ ही साथ सार्वजनिक तरीकों का परीक्षण किया जाना चाहिए। इसलिए मैं उत्पादन कक्षाओं के समान पैकेज में अपनी टेस्ट कक्षाएं चाहता हूं।

2

इस प्रकार हमने इसे स्थापित किया है और हमें यह पसंद है।

build/ 
src/ 
test/build/ 
test/src/ 

सभी परीक्षण कोड अपनी खुद की निर्माण निर्देशिका में संकलित करता है। ऐसा इसलिए है क्योंकि हम नहीं चाहते हैं कि उत्पादन गलती से परीक्षा कक्षाएं रखे।

+0

मैं 'build /' के बजाय 'output /' का उपयोग करूंगा –

0

जब Android Studio में एक जावा पुस्तकालय मॉड्यूल बनाने इसके नीचे एक डिफ़ॉल्ट वर्ग बनाता है:

[module] 
    + src/main/java/[com/foo/bar] 

आप [module].iml फ़ाइल में देखो, तो आप उस पथ के साथ-साथ परीक्षण के लिए पथ मिलेगा, कि तुम उपयोग कर सकते हैं

[module] 
    + src/main/java/[com/foo/bar] 
    + src/test/java/[com/foo/bar] 

ऊपर संरचना Android Studio और आपकी फ़ाइलों द्वारा मान्यता प्राप्त किया जाएगा:

<module> 
    <component> 
    <content> 
     <sourceFolder url="file://$MODULE_DIR$/src/main/java" isTestSource="false" /> 
     <sourceFolder url="file://$MODULE_DIR$/src/main/resources" type="java-resource" /> 
     <sourceFolder url="file://$MODULE_DIR$/src/test/java" isTestSource="true" /> 
     <sourceFolder url="file://$MODULE_DIR$/src/test/resources" type="java-test-resource" /> 
    </content> 
    </component> 
</module> 

क्या आप विशेष रूप से कर सकते हैं परीक्षण निम्नलिखित संरचना है के लिए एक निर्देशिका बनाने के लिए है: नीचे एक सारांश है नीचे मॉड्यूल में शामिल किया जाएगा।

मुझे लगता है कि यह संरचना कोड और परीक्षणों के लिए एक अनुशंसित लेआउट है।

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