कैसे है कि प्रक्रियात्मक या कर रहे हैं कोड की एक इकाई परीक्षण वर्गों करता घटना आधारित

Question

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

अक्सर उदाहरण मैं परीक्षण के लिए देख कक्षाओं का परीक्षण कर रहे हैं - वे एक वस्तु का दृष्टांत, यह नकली डेटा तो देते हैं, बाद में ऑब्जेक्ट के गुणों की जाँच करें। यह मुझे समझ में आता है - लेकिन गैर-ऑब्जेक्ट उन्मुख टुकड़ों के बारे में क्या?

This guy mentioned कि जीयूआई आधारित इकाई परीक्षण सबसे किसी भी परीक्षण ढांचे में मुश्किल है, हो सकता है कि समस्या है। उपर्युक्त प्रस्तुत प्रस्तुति का उल्लेख है कि प्रत्येक परीक्षण को एक समय में एक वर्ग, एक विधि को स्पर्श करना चाहिए। ऐसा लगता है कि मैं क्या करने की कोशिश कर रहा हूं।

तो सवाल - एक इकाई परीक्षण प्रक्रियात्मक या घटना-आधारित कोड कैसे करता है? अच्छे दस्तावेज के लिए एक लिंक प्रदान करें, या इसे स्वयं समझाओ।

एक तरफ ध्यान दें पर, मैं भी एक परीक्षण ढांचे कि xulrunner क्षुधा का परीक्षण करने के लिए सेट है नहीं मिला होने के लिए एक चुनौती है - ऐसा लगता है कि उपकरण बस अभी तक विकसित नहीं कर रहे हैं। मुझे कल्पना है कि यह अवधारणाओं को समझने, टेस्टेबल कोड लिखने, इकाई परीक्षण लागू करने से अधिक परिधीय है।

Answer 1

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

आप एक घटना के आधार पर प्रणाली का परीक्षण इकाई पर योजना है, तो आप अपने जीवन बहुत आसान खुद के लिए अगर आप निर्भरता इंजेक्शन पैटर्न का उपयोग और आदर्श पूरे रास्ते जाने और नियंत्रण के उलट का प्रयोग करेंगे कर देगा (देखें http://martinfowler.com/articles/injection.html और http://msdn.microsoft.com/en-us/library/aa973811.aspx इन पैटर्न का ब्यौरा)

(धन्यवाद ओर इशारा करते हुए के लिए pc1oad1etter करने के लिए मैं लिंक में गड़बड़ था)

Answer 2

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

इसके अलावा, वास्तविक ईवेंट हैंडलर कि घटक 1 से उठाया है, और घटक 2 पर व्यवहार कॉल सिर्फ एकीकरण परीक्षण है जो एक गुणवत्ता आश्वासन व्यक्ति द्वारा मैन्युअल रूप से किया जा सकता है।

Answer 3

पहले तो मुझे इस तरह की घटनाओं का परीक्षण होगा:

private bool fired; 

private void HandlesEvent(object sender, EventArgs e) 
{ 
    fired = true; 
} 

public void Test() 
{ 
    class.FireEvent += HandlesEvent; 
    class.PErformEventFiringAction(null, null); 

    Assert.IsTrue(fired); 
} 

और तब मैं RhinoMocks की खोज की। राइनोमोक्स एक ढांचा है जो नकली वस्तुओं को बनाता है और यह ईवेंट परीक्षण को भी संभालता है। यह आपके प्रक्रियात्मक परीक्षण के लिए भी उपयोगी हो सकता है।

Answer 4

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

Answer 5

बहुधा से जुड़े Working Effectively with Legacy Code देखें। "माई एप्लिकेशन इज ऑल एपीआई कॉल" शीर्षक वाले अनुभाग देखें और "मेरा प्रोजेक्ट ऑब्जेक्ट-ओरिएंटेड नहीं है। मैं सुरक्षित परिवर्तन कैसे करूं?"।

सी/सी ++ दुनिया (मेरा अनुभव) में अभ्यास में सबसे अच्छा समाधान लिंकर "सीम" का उपयोग करना है और परीक्षण के तहत कार्य द्वारा बुलाए गए सभी कार्यों के लिए परीक्षण युगल के खिलाफ लिंक करना है। इस तरह आप किसी भी विरासत कोड को नहीं बदलते हैं, लेकिन आप अभी भी अलगाव में इसका परीक्षण कर सकते हैं।

Answer 6

यहाँ मेरे अपने प्रश्न का उत्तर देना है, लेकिन मैं एक लेख है कि लेने में आए समस्या बताते हैं, और एक सरल उदाहरण के माध्यम से गुजरने के है - Agile User Interface Development। कोड और छवियों महान हैं, और यहाँ एक टुकड़ा है कि इस विचार से पता चलता है:

ऐसे केंट बैक और डेविड Astels रूप

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

Answer 7

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

// Arrange 
var car = new Car(); 
string changedPropertyName = ""; 
car.PropertyChanged += delegate(object sender, PropertyChangedEventArgs e) 
         { 
          if (sender == car) 
            changedPropertyName = e.PropertyName; 
         }; 

// Act 
car.Model = "Volvo"; 

// Assert 
Assert.AreEqual("Model", changedPropertyName, 
    "The notification of a property change was not fired correctly."); 

वर्ग मैं यहाँ का परीक्षण कर रहा हूँ INotifyPropertyChanged इंटरफेस और इसलिए एक NotifyPropertyChanged घटना जब भी एक संपत्ति के मूल्य बदल गया है उठाया जाना चाहिए लागू करता है।