इकाई परीक्षणों को व्यवस्थित करने के लिए और एक दुःस्वप्न को दोबारा नहीं बनाते?

Question

इकाई परीक्षण के आयोजन का मेरे वर्तमान रास्ता निम्नलिखित करने पर निर्भर करता:

• प्रत्येक परियोजना इकाई परीक्षण के साथ अपने स्वयं के समर्पित परियोजना है। एक परियोजना BusinessLayer के लिए, BusinessLayer.UnitTests परीक्षण प्रोजेक्ट है।
• प्रत्येक कक्षा के लिए मैं परीक्षण करना चाहता हूं, परीक्षण परियोजना में एक अलग टेस्ट क्लास है जो बिल्कुल उसी फ़ोल्डर संरचना में और बिल्कुल उसी नामस्थान में परीक्षण के तहत कक्षा के रूप में रखा गया है। एक नामस्थान BusinessLayer.Repositories से CustomerRepository कक्षा के लिए, नामस्थान BusinessLayerUnitTests.Repositories में एक टेस्ट क्लास CustomerRepositoryTests है।

प्रत्येक टेस्ट क्लास के भीतर विधि सरल नामकरण सम्मेलन MethodName_Condition_ExpectedOutcome का पालन करें। तो वर्ग CustomerRepositoryTests कि एक Get विधि परिभाषित के साथ एक कक्षा CustomerRepository के लिए परीक्षण में शामिल है ऐसा दिखाई देता है:

[TestFixture] 
public class CustomerRepositoryTests 
{ 
    [Test] 
    public void Get_WhenX_ThenRecordIsReturned() 
    { 
     // ... 
    } 

    [Test] 
    public void Get_WhenY_ThenExceptionIsThrown() 
    { 
     // ... 
    } 
} 

यह दृष्टिकोण मुझे काफी अच्छी तरह से सेवा की है, क्योंकि यह वास्तव में सरल कोड के कुछ टुकड़े के लिए परीक्षण का पता लगाने में आता है। विपरीत साइट पर, यह कोड को वास्तव में अधिक कठिन बना देता है, तो यह होना चाहिए:

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

वहाँ इकाई परीक्षण है कि अभी भी मुझे एक ही समय में जल्दी से एक विशिष्ट कोड के लिए परीक्षण का पता लगाने का और पुनर्रचना की ओर ही अधिक उधार देने की अनुमति होगी के आयोजन के कुछ चालाक रास्ता नहीं है?

वैकल्पिक रूप से, वहाँ कुछ, उह, शायद दृश्य स्टूडियो विस्तार है, कि अनुमति होगी मुझे किसी भी तरह कहना है कि "अरे, इन परीक्षण कर रहे हैं कि विधि के लिए है, इसलिए जब विधि परिवर्तन के नाम पर है, तो कृपया दयालु और परीक्षण भी बदलते हैं "? ईमानदार होने के लिए, मैं गंभीरता से कुछ लिखने पर विचार कर रहा हूं :)

Answer 1

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

[TestFixture] 
public class MyFunctionalityTests 
{ 
    public IEnumerable<Type> TestedClasses() 
    { 
     // We can find the tests for a class, because the test cases references in some special method. 
     return new []{typeof(SomeTestedType), typeof(OtherTestedType)}; 
    } 

    [Test] 
    public void TestRequirement23423432() 
    { 
     // ... test code. 
     this.TestingMethod(someObject.methodBeingTested); //We do something similar for methods if we want to track which methods are being tested (we usually don't) 
     // ... 
    } 
} 

हम परीक्षण मामलों, आदि खोजने के लिए "उपयोगिताएं" ReSharper जैसे टूल का उपयोग कर सकते हैं ... और जब वह पर्याप्त नहीं है, हम कुछ जादू सभी परीक्षण वर्गों को लोड करके प्रतिबिंब और LINQ द्वारा, और allTestClasses.where(testClass => testClass.TestedClasses().FindSomeTestClasses()); जैसे कुछ चलाना आप प्रत्येक विधि/वर्ग द्वारा कौन सी विधियों का परीक्षण किया जाता है और यह भी करने के बारे में जानकारी एकत्र करने के लिए टियरडाउन का उपयोग भी कर सकते हैं।

Answer 2

प्रति परियोजना एक इकाई परीक्षण परियोजना जाने का तरीका है। हमने मेगा यूनिट टेस्ट प्रोजेक्ट के साथ प्रयास किया है लेकिन इसने संकलन समय बढ़ाया है।

resharper या code rush जैसे उत्पाद का उपयोग करने में आपकी सहायता के लिए।

Answer 3

वहाँ इकाई परीक्षण है कि अभी भी मुझे एक विशिष्ट कोड के लिए परीक्षण का पता लगाने की जल्दी

Resharper की अनुमति होगी के आयोजन के कुछ चालाक रास्ता नहीं है कुछ अच्छी लघु कटौती है कि आप फ़ाइल या कोड खोज करने के लिए अनुमति देता है

आप वर्ग CustomerRepository के लिए कहा के रूप में उनके लिए एक परीक्षण CustomerRepositoryTests

आर # शॉर्टकट आप क्या लगता है के लिए बॉक्स inpput से पता चलता है आप केस आप कर सकते हैं बस इनपुट CRT और कहीं भी होगी रों कैसे आप सब नाम के साथ शुरू फ़ाइलों राजधानी सी के रूप में पहली है तो आर और फिर टी

यह भी आप इस तरह के सीआर * के रूप में वाइल्ड कार्ड और CustomerRepositoryTests

Answer 4

एक आप फ़ाइल CustomerRepository की सूची दिखाई देगी द्वारा खोज करते हैं की अनुमति देते हैं जब कोड का स्थान बदलना सिंक में वर्ग और परीक्षण स्थानों रखने के लिए जिस तरह से:

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

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

Answer 5

वीएस एक्सटेंशन के संबंध में जो कोड को परीक्षण में जोड़ते हैं, विजुअल स्टूडियो के टेस्ट इंपैक्ट पर एक नज़र डालें। यह एक प्रोफाइलर के तहत परीक्षण चलाता है और एक कॉम्पैक्ट डेटाबेस बनाता है जो आईएल अनुक्रम बिंदुओं को यूनिट परीक्षणों में मैप करता है। तो दूसरे शब्दों में, जब आप कोड बदलते हैं तो विजुअल स्टूडियो जानता है कि कौन से परीक्षणों को चलाने की आवश्यकता है।