2008-09-17 13 views
22

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

डिबगिंग के लिए ठीक है, लेकिन एक बार मैं एक रिलीज़ संस्करण निर्माण, मैं वास्तव में नहीं है मेरे कोड संदर्भ इकाई परीक्षण रूपरेखा किसी भी अधिक करना चाहते हैं।

मुझे मिला एक समाधान #if DEBUG - #endif निर्देशों के भीतर आपके सभी यूनिट परीक्षणों को संलग्न करना है: जब कोई कोड यूनिट परीक्षण असेंबली का संदर्भ नहीं देता है, तो संकलक संकलित कोड में संदर्भ को छोड़ने के लिए पर्याप्त चालाक होता है।

क्या कोई अन्य लक्ष्य प्राप्त करने के लिए कोई अन्य (संभवतः अधिक आरामदायक) विकल्प हैं?

उत्तर

40

मैं निश्चित रूप से एक अलग परियोजना में अपने परीक्षणों को अलग करने का समर्थन करता हूं। मेरी राय में जाने का यही एकमात्र तरीका है।

हाँ, के रूप में Gary कहते हैं, यह भी मजबूर करता यदि आप अपने वर्गों के धर्मशाला

+3

यह आपको अपनी कक्षाओं के अंदरूनी भाग के बजाए सार्वजनिक तरीकों के माध्यम से व्यवहार का परीक्षण करने के लिए भी मजबूर करता है। डबल बोनस आईएमओ। –

+0

मैं भी एक अलग फ़ोल्डर संरचना की सिफारिश करेंगे। ProjName \ Code \ SubPackage और ProjName \ Test \ SubPackage। – Gishu

+0

यदि आपको व्हाइटबॉक्स-परीक्षण की आवश्यकता है तो क्या होगा? –

1

मैं हमेशा एक अलग परियोजना में मेरी इकाई परीक्षण रख दिया है ताकि वह करने के लिए संकलित साथ के बारे में खेल रहे हैं की तुलना में सार्वजनिक विधियों के माध्यम से व्यवहार का परीक्षण करने यह अपनी असेंबली है।

2

प्रत्येक प्रोजेक्ट के लिए एक संबंधित है। नवीनतम परियोजना जिसमें परीक्षण शामिल हैं।

उदा। असेंबली के लिए, "Acme.BillingSystem.Utils" कहें, "Acme.BillingSystem.Utils.Test" नामक एक परीक्षण असेंबली होगी।

शिपिंग कि dll नहीं द्वारा अपने उत्पाद की शिपिंग संस्करण से यह बाहर निकालें।

3

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

समानांतर नामस्थान को बनाए रखने और परीक्षण के लिए एक समझदार नामकरण परंपरा (जैसे। MyClass और MyClassTest) का उपयोग कर आप codebase पोषणीय रखने में मदद मिलेगी। वी 2 के बाद

10

नेट ढांचा एक उपयोगी सुविधा जहां InternalsVisibleTo विशेषता विधानसभा किसी अन्य के द्वारा पहुँचा जा सकता है उस के साथ एक विधानसभा चिह्नित कर सकते हैं है।
असेंबली सुरंग सुविधा का एक प्रकार।

19

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

एक बात आप 'आंतरिक' एक्सेसर साथ वर्गों और तरीकों का परीक्षण करना चाहते हैं तो याद करने के लिए AssemblyInfo में निम्न पंक्ति जोड़ने के लिए है।प्रत्येक परियोजना के लिए सीएस फ़ाइल परीक्षण किया जाना:

[assembly: InternalsVisibleTo("UnitTestProjectName")] 
+0

धन्यवाद, यह एक साफ चीज है जिसे मुझे पता नहीं था। –

+0

धन्यवाद भी! इसका मतलब है कि हम परीक्षणों के लिए चीजों को सार्वजनिक करने से रोक सकते हैं! : डी –

+2

यदि आप अपनी असेंबली को मजबूत करते हैं (जैसा कि आपको करना चाहिए), तो आपको घोषणा के लिए सार्वजनिक कुंजी लंबी स्ट्रिंग भी जोड़नी होगी। नोट: मजबूत नामकरण आंतरिक के लिए तीसरे पक्ष के संबंध के खिलाफ सुरक्षा नहीं है, क्योंकि उन्हें अभी भी प्रतिबिंब के माध्यम से उपयोग किया जा सकता है। –

0

मैं निश्चित रूप से किसी और है कि आप अपने उत्पादन कोड से परीक्षण बांट देना चाहिए हर किसी के साथ सहमत हैं। आप नहीं पर जोर देते हैं, हालांकि, आप एक सशर्त comiplation लगातार परीक्षण कहा जाता निर्धारित करें और यह सुनिश्चित करें कि परीक्षण कोड एक उत्पादन परिदृश्य में संकलन नहीं करता है के साथ एक

#if TEST 
#endif 

पहली बार अपने इकाई परीक्षण कक्षाओं के सभी लपेट चाहिए। एक बार ऐसा करने के बाद, आपको या तो अपने उत्पादन परिनियोजन से परीक्षण डीएलएस को बाहर करने में सक्षम होना चाहिए, या यहां तक ​​कि बेहतर (लेकिन उच्च रखरखाव), उत्पादन के लिए एक NANT या MSBuild बनाएं जो परीक्षण डीएलएस के संदर्भों के बिना संकलित हो।

2

जब तक आपके परीक्षण एक अलग परियोजना में हैं, परीक्षण कोडबेस का संदर्भ दे सकते हैं, लेकिन कोडबेस को कभी भी परीक्षणों का संदर्भ नहीं देना पड़ता है। मुझे पूछना है, दो परियोजनाओं को बनाए रखने के बारे में क्या भ्रमित है? आप उन्हें संगठन के लिए एक ही समाधान में रख सकते हैं।

जटिल हिस्सा, ज़ाहिर है, जब व्यापार में समाधान में 55 परियोजनाएं होती हैं और उनमें से 60% परीक्षण होते हैं। अपने आप को भाग्यशाली गणना करें।

0

मैं हमेशा एक अलग Acme.Stuff.Test प्रोजेक्ट बनाता हूं जिसे अलग से संकलित किया जाता है।

बातचीत तर्क यह है कि: आप परीक्षण क्यों लेना चाहते हैं? परीक्षण क्यों नहीं देते? यदि आप परीक्षण धावक के साथ परीक्षण प्रदान करते हैं तो आपके पास उत्पाद के साथ स्वीकृति परीक्षण और स्वयं परीक्षण का कुछ स्तर होता है।

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

2

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

6

फिर भी फ़ाइल के भीतर कंपाइलर निर्देशों का उपयोग करने या एक अलग परियोजना बनाने का एक और विकल्प केवल आपकी परियोजना में अतिरिक्त .cs फ़ाइलों को बनाने के लिए है।

प्रोजेक्ट फाइल अपने आप में कुछ जादू के साथ

, तो आप उस हुक्म कर सकते हैं:

  1. nunit.framework DLLs केवल एक डीबग बिल्ड में संदर्भित, और
  2. अपने परीक्षण फ़ाइलों को केवल शामिल किए गए हैं डिबग बनाता में

उदाहरण .csproj अंश:

<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="3.5"> 

    ... 

    <Reference Include="nunit.framework" Condition=" '$(Configuration)'=='Debug' "> 
     <SpecificVersion>False</SpecificVersion> 
     <HintPath>..\..\debug\nunit.framework.dll</HintPath> 
    </Reference> 

    ... 

    <Compile Include="Test\ClassTest.cs" Condition=" '$(Configuration)'=='Debug' " /> 

    ... 
</Project> 
1

एक बात अभी तक होने के लिए माना जाता है कि 2005 से पहले विजुअलस्टूडियो के संस्करणों ने EXE असेंबली परियोजनाओं को अन्य परियोजनाओं से संदर्भित करने की अनुमति नहीं दी थी। तो अगर आप VS.NET में एक विरासत परियोजना पर काम कर रहे हैं अपने विकल्पों को होगा:

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

तीन सशर्त संकलन में से कम से कम त्रुटि प्रवण है।

0

यदि #if (DEBUG) टैग एक साफ "रिलीज" संस्करण की अनुमति देता है, तो आपको परीक्षणों के लिए एक अलग परियोजना की आवश्यकता क्यों होगी। नूनिट लिबारी ए/बी उदाहरण (हाँ, मुझे इसका एक उदाहरण पता है) यह करता है। वर्तमान में परिदृश्य के साथ कुश्ती। एक अलग परियोजना का उपयोग कर रहा था, लेकिन ऐसा लगता है कि संभवतः कुछ उत्पादकता सुधारों की अनुमति है। अभी भी hummin और hawin।