2008-11-19 20 views
11

वर्तमान में, मैं पैकेज (परियोजनाओं) द्वारा अपने सभी परीक्षणों को विभाजित कर रहा हूं। इसलिए यदि मेरे पास 12 परियोजनाएं हैं, तो मैं 12 कक्षाओं के साथ यूनिट टेस्ट के लिए 1 और परियोजना तैयार करूंगा जो मेरे सभी पैकेज का परीक्षण करेगी।यूनिटटेस्ट आप अपनी परीक्षण फाइलों को व्यवस्थित कैसे करते हैं?

क्या आप वही करते हैं या आपके पास कक्षा द्वारा 1 परीक्षण कक्षा है? आप अपने सभी परीक्षण कैसे व्यवस्थित करते हैं?

package/Class.cpp 
package/Class.hpp 
package/test/ClassUnitTest.cpp 
package/test/ClassIntegrationTest.cpp 
test/unit-test/main.cpp 
test/integration-test/main.cpp 
test/data 
test/tmp 

कहाँ इकाई परीक्षण और एकीकरण परीक्षण सिर्फ परीक्षण धावक, परीक्षा/डेटा हैं कि उपयोग किया जाता है डेटा फ़ाइलों को रखती है:

उत्तर

4

पोकस की तरह मेरे परीक्षण परीक्षण के लिए कक्षाओं के समान असेंबली में हैं इसलिए मैं आंतरिक और निजी परीक्षण कर सकता हूं।

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

मैं टेस्ट नामक एक फ़ोल्डर जोड़ता हूं जिसमें मेरी टेस्ट कक्षाएं होती हैं। कक्षा 1 सी में एक टेस्ट क्लास टेस्ट \ Class1UnitTest.cs है।

शायद बेहतर तरीके से, लेकिन यह मेरे लिए काम करता है।

+0

मुझे लगता है कि मैं ऐसा करूँगा। अच्छा विचार –

+0

यह तब भी आसान होता है जब आप या तो प्रोजेक्ट टेम्पलेट बदलते हैं या अपना स्वयं का बनाते हैं, ताकि यूनिटटेस्ट बिल्ड कॉन्फ़िगरेशन पहले से मौजूद हो। – xando

+0

बहुत चालाक। मैंने सिर्फ पूरे सुझाव पढ़े हैं और मैं तुम्हारा अपनाना चाहूंगा। धन्यवाद। –

3

हम इसे इस (C++) की तरह का आयोजन किया है एकीकरण परीक्षण और परीक्षण/tmp द्वारा एक ही परीक्षण द्वारा बनाई गई अस्थायी फ़ाइलें रखती हैं और प्रत्येक परीक्षण सूट के लिए साफ़ की जाती है।

4

क्योंकि मैं टीडीडी करता हूं, मेरे पास प्रत्येक वर्ग के लिए एक टेस्ट क्लास है, और उन परीक्षण कक्षाओं को वास्तविक परियोजना में परीक्षण परियोजना के एक मिलान के लिए सीधे एक समूह में समूहित करें। समाधान के आकार के आधार पर, परीक्षण परियोजनाएं या तो एक ही समाधान (यदि छोटी हो) में मौजूद होती हैं, या अलग-अलग समाधानों में विभाजित हो जाती हैं (यदि बड़ा हो)

1

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

एक उदाहरण के रूप (नहीं मेरा असली पैकेज के नाम):

src.com.app 
src.com.app.model 
src.com.app.view 
src.com.app.controller 

tests.com.app 
tests.com.app.model 
tests.com.app.view 
tests.com.app.controller 
6

एक जावा/Maven सेटिंग में:

project/src/main/java/Package/Class.java 
project/src/test/java/Package/ClassTest.java 
project/src/main/resources/Package/resource.properties 
project/src/test/resources/Package/test_resource.properties 
+0

मेवेन परियोजना इकाई के साथ स्थिरता को सुविधाजनक बनाने में सहायता के लिए उत्कृष्ट है जिसमें आपके यूनिट परीक्षणों को कैसे व्यवस्थित किया जाए। – rich

+0

मेरे पास एक ही निर्देशिका में संसाधनों के साथ मेरा प्रोजेक्ट संरचित प्रोजेक्ट/src/package और project/testcases/पैकेज है, लेकिन मैं अन्य तरीकों की तुलना में ग्रहण से मैवेन आया था। मेवेन मुझे स्रोत संरचनाओं को मेरी संरचना में किसी भी तरह से ओवरराइड करने की अनुमति देता है। –

+0

@ माइकल: मूल रूप से मैवेन के साथ सबकुछ संभव है। लेकिन हम संसाधनों और स्रोतों के बीच स्पष्ट अलगाव चाहते थे (हमारे पास कई संसाधन हैं)। मैं नहीं कहता कि एक तरफ दूसरे की तुलना में बेहतर है। हमने अभी इस तरह चुना है। – boutta

1

मैं अपने प्रोजेक्ट जहां वर्ग के हैं में अपने परीक्षण वर्ग की है। इस तरह मैं आंतरिक सामान का परीक्षण कर सकता हूं। मैं कक्षा के नाम पर "टेस्ट" पोस्टफिक्स जोड़ता हूं। उदाहरण: MyClass.cs MyClassTest.cs

0

हम एक-से-एक परीक्षण असेंबली (सी #) करते हैं। समाधान में प्रत्येक असेंबली के लिए, हमारे पास एक संबंधित परीक्षण परियोजना है। प्रत्येक परियोजना में संबंधित परियोजना में प्रत्येक वर्ग के लिए एक परीक्षण होता है।

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

कंपनी। उत्पाद।फ़ीचर
    ClassnameAlpha
    ClassnameBeta
    ClassnameDelta

Company.Product.Feature.UnitTests
    ClassnameAlphaTests
    ClassnameBetaTests
    ClassnameDeltaTests

मैं लेता हूं कि xando थोड़ा आगे क्या करता है। डिफ़ॉल्ट डीबग/रिलीज कॉन्फ़िगरेशन का उपयोग करने के बजाय, मेरे पास प्रत्येक शाखाओं के लिए कॉन्फ़िगरेशन है जिसका उपयोग हम टीम फाउंडेशन सर्वर में कॉन्फ़िगरेशन बनाने के लिए करते हैं। इसलिए, मेरे पास विकास, एकीकरण और उत्पादन है। दिमाग में नुकीले उबाऊ विनिर्देशों के बिना, यूनिट परीक्षण विकास और एकीकरण विन्यास के लिए बनाए जाते हैं। उन्हें उत्पादन शाखा में शामिल किया गया है, लेकिन निर्माण के साथ संकलित नहीं किया गया है। कारणों को शामिल करने का कारण यह है कि जब हमें उत्पादन से बाहर करना होगा (उदाहरण के लिए एक हॉटफिक्स) यूनिट परीक्षणों को संशोधित कोड के साथ चलाया जा सकता है, संशोधित किया जा सकता है, और रिवर्स-एकीकृत किया जा सकता है।

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

1

मुझे एक ही पैकेज में मेरा स्रोत और परीक्षण मौजूद होना पसंद है। इसलिए मैं निम्नानुसार मेरा आयोजन करता हूं:

src/com/company/package/Class.java 
testsrc/com/company/package/ClassTest.java 
1

मैं उन्हें पूरे उत्पाद के लिए एक अलग पैकेज में रखता हूं। मैं यूनिट टेस्ट कोड के साथ उत्पादन कोड को अव्यवस्थित करना पसंद नहीं करता हूं।

 
Company/Product/Package1 
Company/Product/PackageN 
Company/Product/UnitTest/Package1/Class/Method1Fixture.cs 
Company/Product/UnitTest/Package1/Class/MethodNFixture.cs 
Company/Product/UnitTest/PackageN/Class/Method1Fixture.cs 
Company/Product/UnitTest/PackageN/Class/MethodNFixture.cs 

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

0

मुझे कोड कोड के नजदीक रखना है, जो आमतौर पर एक अलग उप निर्देशिका में समर्थन करते हैं। इस तरह से मैं उन्हें कोड के साथ संकलित कर सकता हूं, जो उन्हें दृश्यमान बनाता है - यह महत्वपूर्ण है विरासत परियोजनाएं जब केवल कुछ घटकों में इकाई परीक्षण होते हैं।

.../component/src/ 
       /include/ 
       /doc/ 
       /bin/ 
       /test/ 

हमारे पास आम तौर पर बाइनरी प्रति एक सूट होता है, लेकिन इसमें अपवाद हैं। हम किसी भी निर्देशिका के तहत एक सरल कमांड के साथ सभी परीक्षण चला सकते हैं।

अंगूठे का नियम यूनिट परीक्षणों को ढूंढना आसान है, संकलित करने में आसान है और चलाने में आसान है ताकि वे किसी के रास्ते में न आएं।

0

मेरे पास परीक्षण की श्रेणी द्वारा आयोजित मेरा परीक्षण है। यदि मेरी सभी यूनिट परीक्षण फ़ाइल 1 निर्देशिका में है। 1 निर्देशिका में सभी एकीकरण। मेरे पास एक दूसरे में दृढ़ता परीक्षण है।परीक्षण करने के लिए प्रत्येक फ़ोल्डर में सभी फ़ोल्डर्स की कई फाइलें होती हैं।

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