कैसे मैंने एक साइकिल का आविष्कार किया, प्रौद्योगिकी का अध्ययन किया

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

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

साइकिल चलाने का थीम

मुझे लंबे समय तक चयन नहीं करना पड़ा, समाधान का शाब्दिक अर्थ अपने आप आ गया - फ़िल्टरिंग और एक विन्यास योग्य आउटपुट प्रारूप के साथ अपना स्वयं का लकड़हारा लिखना। मैं ASP.Net, और MVC3 ढांचे के बारे में अपना पहला लेख लिखना चाहता था। हालांकि अब यह पहले से ही MVC4 की ओर बढ़ने का मतलब है। प्रौद्योगिकियों के बीच, वैसे, यह एंटिटी फ्रेमवर्क का उपयोग करने वाला था। इस विषय पर पहले से ही एक लेख है, लेकिन लेखक वादा पूरा किए बिना गायब हो गया।
तो मैं एक लकड़हारे से क्यों बाधित हूं? निश्चित रूप से उस एप्लिकेशन को बनाने की प्रक्रिया में, लॉगिंग की आवश्यकता उत्पन्न हुई। मुझे NLG में उपलब्ध NLog लेने की सलाह दी गई थी, लेकिन इसका अध्ययन करने के बाद, मैं इस निष्कर्ष पर पहुंचा कि मेरा लकड़हारा लिखना न केवल दिलचस्प है, बल्कि उचित भी है। मैंने खुद इसकी जांच नहीं की, लेकिन इंटरनेट पर समीक्षाओं को देखते हुए, log4net इसकी तुलना में धीमा है, इसलिए मैंने इस पर विचार नहीं किया।
मैं खुद टेलीकॉम में काम करता हूं, और मुझे पहले से ही लकड़हारे के साथ काम करना पड़ता था, जब कार्यक्षमता की आवश्यकता थी जो मानक syslogs में अनुपस्थित था। यह आईडी द्वारा फ़िल्टरिंग है। जब कोई साइट प्रति घंटे 30 हजार कॉल की प्रक्रिया करती है, तो भले ही उस पर बग का 100% पुनरुत्पादन हो, लेकिन मेगाबाइट में उसे खोजना और यहां तक ​​कि लॉग की गीगाबाइट भी इतना सरल नहीं है। हां, और सभी सिस्टम आपको लॉग की गीगाबाइट स्टोर करने की अनुमति नहीं देते हैं, कुछ स्थानों पर ऐसे सिस्टम हैं जो केवल कुछ घंटों का ट्रैफ़िक प्राप्त करते हैं और कॉल स्वयं लंबे समय तक हो सकती है, अर्थात कॉल की शुरुआत या अंत लॉग में नहीं हो सकता है। इसलिए, "ऊपर से" विचार आया - कॉल को चिह्नित करके सही बात को उजागर करने के लिए ताकि केवल वह लॉग में हो जाए। खैर, या कुछ कॉल, लेकिन केवल उस संख्या पर जहां यह बग समय-समय पर होता है। सिसलॉग को सफलतापूर्वक मैक्रो द्वारा बदल दिया गया था जो ऑपरेटर द्वारा निर्दिष्ट पहचानकर्ताओं की सूची के साथ सत्र में पहचानकर्ता की तुलना करता है। पहचानकर्ता टर्मिनल के अनूठे पते और डायल किए गए नंबर दोनों से बंधा हुआ था। मेरे ASP.Net अनुप्रयोग में, फ़िल्टरिंग को उपयोगकर्ता द्वारा माना जाता था। बेशक, यह यहाँ बहुत उचित नहीं हो सकता है, लेकिन जब से मैंने फैसला किया कि लकड़हारे को इस सुविधा की आवश्यकता है, तो ऐसा ही हो।
दूसरा बाइक अवसर मुझे NLog के लिए स्रोत कोड का अध्ययन करके मिला। इसमें, कॉलिंग थ्रेड के संदर्भ में लगभग सभी क्रियाएं की जाती हैं, अतुल्यकालिक रूप से केवल सीधे लेखन को लक्षित किया जाता है। वह, जिसे मैं बाद में आश्वस्त हो गया, प्रदर्शन के लिए काफी नुकसान करता है।

एक अलग धागे पर संचालन डाल रहा है

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

public delegate void ReceiveHandler<T>(T item); public interface IQueued<T> { event ReceiveHandler<T> OnReceive; event Action OnTimeout; bool Active { get; } void setTimeout(int timeout); void Send(T msg); void Terminate(); } 

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

 thread = new Thread(ThreadRun); thread.Start(); 

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

 ThreadPool.QueueUserWorkItem(ThreadRun); 

कंस्ट्रक्टर मैनुअलएनेटइवेंट को एक इनपुट के रूप में स्वीकार करता है, जिसे थ्रेड्स के साथ काम करने वाले कई वर्गों को खिलाया जा सकता है, और फिर इसे एक केंद्रीकृत अनुप्रयोग समाप्ति घटना के रूप में उपयोग कर सकता है। मैंने लकड़हारे में इसका उपयोग नहीं किया, लेकिन सिर्फ इस मामले में मैंने इस अवसर को जोड़ा। समापन कार्यक्रम के अलावा, एक ईवेंट का उपयोग कार्य करने के लिए भी किया जाता है, जिसका अर्थ है कि कतार में एक नया संदेश आया है। ऐसा दिखता है

  EventWaitHandle[] events = new EventWaitHandle[2]; ... events[0] = new AutoResetEvent(false); events[1] = terminateEvent ?? new ManualResetEvent(false); 

यहाँ यह बिल्कुल स्पष्ट है कि टर्मिनेट पद्धति का कार्य घटनाओं [1] को एक पर सेट करना है।
प्रेषित संदेशों को संग्रहीत करने के लिए, मैंने कतार की कतार का उपयोग किया; भेजें () विधि को केवल एक उदाहरण से कॉपी किया जाता है:

  lock (queSync) { queue.Enqueue(msg); } events[0].Set(); 

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

  while ((index = WaitHandle.WaitAny(events, currentTimeout)) != 1) 

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

  if (index == WaitHandle.WaitTimeout) { OnTimeout(); currentTimeout= Timeout.Infinite; } 

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

  Queue<T> replacement = new Queue<T>(); Queue<T> items; lock (queSync) { items = queue; queue = replacement; } foreach (T t in items) { OnReceive(t); } currentTimeout = timeout; 

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

टीडीडी की शुरुआत

मैं विषय पर थोड़ा सैद्धांतिक हूं। सबसे पहले, उस वर्ग के उदाहरण पर, जो पहले था, और दूसरा समान था, विकास व्यवहार को टीडीडी के तहत अभिव्यक्त नहीं किया जा सकता था, जहां पहले परीक्षण, फिर कोड ही। मेरे विकास का मार्ग निम्न चरणों से गुजरा - कार्य कोड लिखना, फिर परीक्षण के मामले लिखना, फिर पहले और दूसरे दोनों को समायोजित करना, मानक तक लाना। उसके बाद, परीक्षण "सत्य के रूप में पहचाने जाते हैं", और रिफैक्टरिंग, जो बाद में अनुसरण करते हैं, अच्छी तरह से उन पर आधारित हो सकते हैं। मुझे क्यों लगता है कि इस दृष्टिकोण को जीवन का अधिकार है, कम से कम शुरुआत के लिए: यदि हम सरलतम कार्य A = B + C पर विचार करते हैं, तो इस फ़ंक्शन का परीक्षण सूत्र C1 = A - B द्वारा सुझाया जाता है, और फिर तुलना C के आधार पर परीक्षण की सफलता का निष्कर्ष निकाला जाता है। == C1। यहां त्रुटियां परीक्षण किए गए फ़ंक्शन और परीक्षण एक दोनों में निहित हो सकती हैं। इससे भी अधिक, चूंकि इसमें अधिक क्रियाएं हैं, एक गलती अधिक होने की संभावना है। इस बिंदु पर, किसी को आश्चर्य हो सकता है कि परीक्षण आखिर क्यों आवश्यक है, लेकिन जवाब स्वाभाविक रूप से पहले से मौजूद है, हमारे सामने सब कुछ तैयार है। परीक्षण "पारित" दिखाने के लिए, शर्तों में से एक को पूरा करना होगा। दोनों कार्यों में त्रुटियों की अनुपस्थिति, या एक त्रुटि दोनों की एक साथ मौजूदगी। दोनों त्रुटियों के होने की संभावना अलग-अलग प्रत्येक त्रुटि की संभावना से कम है, खासकर क्योंकि यहां उपस्थिति पर्याप्त नहीं है, यह भी आवश्यक है कि त्रुटियां synergistic हैं, अर्थात, एक दूसरे के प्रभाव के लिए क्षतिपूर्ति करते हैं, जिसकी संभावना और भी कम है। यही है, परीक्षणों को लिखने के सभी प्रयास सीधे त्रुटियों की संभावना को कम करने के उद्देश्य से हैं। हालांकि, जब एक ही व्यक्ति द्वारा परीक्षण और कोड दोनों लिखे जाते हैं, तो वह एक ही गलती करेगा इसकी संभावना थोड़ी अधिक है। ठीक है, ठीक है, यह मुझे लगता है कि साइकिल के लिए, और जो पहले से ही अच्छा है।
पहले परीक्षणों को लिखने के लिए आगे बढ़ते हैं। ऐसा करने के लिए, पहले IQueued इंटरफ़ेस नाम पर राइट-क्लिक करके और संबंधित मेनू आइटम का चयन करके एक परीक्षण टेम्पलेट बनाएं। तो, इस वर्ग का परीक्षण करने में क्या लगता है। इसे अलग-थलग करने के लिए परीक्षण करना चाहिए, फिर आपको उन कक्षाओं की मोकी (नकल करने वाले) बनाने की ज़रूरत है जो विषय वर्ग के साथ बातचीत करते हैं। एक अन्य बिंदु यह है कि चूंकि परीक्षण का उद्देश्य एक इंटरफ़ेस चुनना था, और शुरुआत में दो विशिष्ट कक्षाएं थीं जिन्हें परीक्षण करने की आवश्यकता है, और बाद में 2 के 2 के 4 संयोजनों की, यह एक अमूर्त संशोधक के साथ नए सिरे से बनाए गए परीक्षण वर्ग को पुरस्कृत करने और इसमें एक सामान्य पैरामीटर जोड़ने के लिए समझ में आता है।

  [TestClass()] public abstract class IQueuedTest<T> 

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

  class Tester<T1> 

यह वर्ग परीक्षण किए गए वर्ग की घटनाओं की सदस्यता लेगा, घटनाओं के ट्रिगर पर विचार करेगा, और याद रखेगा कि इस घटना में क्या हुआ था।

  public Tester(IQueued<T1> tested) { tested.OnReceive += Received; tested.OnTimeout += TimeOut; } void TimeOut() { timedCount++; } void Received(T1 item) { Thread.Sleep(delay); receivedCount++; lastItem = item; } 

इस आंतरिक वर्ग के अतिरिक्त, आपको विशिष्ट ऑब्जेक्ट बनाने के लिए तरीकों की आवश्यकता होगी, जिसे हम सभी उत्तराधिकारियों को ओवरराइड करने के लिए उपकृत करेंगे।

  protected abstract IQueued<T> createSubject(); protected abstract T CreateItem(); 

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

  void ActivationTestHelper(Tester<T> tester, IQueued<T> subject) { int retry = 30; while (!subject.Active && retry > 0) { retry--; Thread.Sleep(SleepDelay); } Assert.AreEqual(true, subject.Active); } 

धारा सक्रिय होने तक "प्रतीक्षा" करने के 30 प्रयास, जिसके बाद केवल परीक्षण के लिए आगे बढ़ें। सृजन के तुरंत बाद सहायक को बुलाया जाएगा।
और, फिर से - तो, ​​परीक्षण लिखने के लिए। एक संदेश भेजने-प्राप्त करने के लिए पहला परीक्षण है। चूँकि हम जानते हैं कि कक्षा का कार्य किसी अन्य सूत्र में स्थानांतरित करना है, इसलिए हमें यह सुनिश्चित करने की आवश्यकता है कि परीक्षक वर्ग को भेजने वाले स्ट्रीम के संदर्भ में एक संदेश प्राप्त नहीं होता है, फिर सुनिश्चित करें कि यह सफलतापूर्वक प्राप्त होता है। यह इसके लिए है (पहली बार), वैसे, परीक्षक को प्राप्त विधि के कोड में 50ms की देरी है। यदि कॉलिंग थ्रेड में यह विलंब होता है, तो पहला अभिकर्ता परीक्षण में विफल हो जाएगा।

  [TestMethod()] public void SendTest() { var subject = createSubject(); var tester = new Tester<T>(subject); ActivationTestHelper(tester, subject); T item = CreateItem(); tester.delay = SleepDelay; subject.Send(item); Assert.AreEqual(0, tester.receivedCount); 

अगला, यह सुनिश्चित करने के लिए कि संदेश प्रेषित है, हम 100ms प्रतीक्षा करेंगे और प्राप्त एक की जांच करेंगे। सिद्धांत रूप में, इन मूल्यों को कम किया जा सकता है, मुख्य बात यह है कि दूसरी देरी पहले की तुलना में अधिक है, लेकिन यहां, मुझे लगता है कि यह अप्रत्याशित है। निम्नलिखित परीक्षणों के लिए "रास्ता" देने के लिए प्रवाह को पूरा करने के लिए मत भूलना।

  Thread.Sleep(SleepDelay2); Assert.AreEqual(1, tester.receivedCount); Assert.IsTrue(tester.lastItem.Equals(item)); subject.Terminate(); } 

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

  [TestMethod()] public void TimeoutTest() { var subject = createSubject(); var tester = new Tester<T>(subject); subject.setTimeout(SleepDelay); ActivationTestHelper(tester, subject); T item = CreateItem(); subject.Send(item); Assert.AreEqual(0, tester.timedCount); Thread.Sleep(SleepDelay3); Assert.AreEqual(1, tester.timedCount); } 

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

  public void TerminateTest() { ... subject.Terminate(); subject.Send(item); Thread.Sleep(SleepDelay3); Assert.AreEqual(0, tester.receivedCount); Assert.AreEqual(0, tester.timedCount); } 

इंटरफ़ेस में केवल तीन परीक्षण हैं, लेकिन दो विशिष्ट कक्षाएं हैं, स्ट्रीम शुरू करने के लिए दो और विकल्प हैं, और इसके बाद, मैंने अलग से यह जांचने का निर्णय लिया कि यह संचरित संदेश के रूप में कक्षाओं और संरचनाओं के साथ कैसे काम करता है। क्यों 8 विशिष्ट परीक्षण कक्षाएं बनाई जाती हैं, जिनमें से एक मैं दूंगा, और विशिष्ट परीक्षण मामलों की संख्या 24 है। परीक्षण संरचना:

  public struct TestMessageStruct { public string message; //object reference field public int id; //value field } 

और वास्तव में एक विशिष्ट परीक्षण वर्ग जो विकल्प का परीक्षण करता है: एक अवरुद्ध कतार, एक नियमित धागा, एक संरचना।

  [TestClass()] public class IQueuedLockRegTest : IQueuedTest<TestMessageStruct> { protected override IQueued<TestMessageStruct> createSubject() { return new LockQueued<TestMessageStruct>(new RegularThreadStarter()); } protected override TestMessageStruct CreateItem() { var item = new TestMessageStruct(); var rnd = new Random(); item.id = rnd.Next(); item.message = string.Format("message {0}", item.id); return item; } } 

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

लकड़हारा इंटरफ़ेस और पहली फ़िल्टर परत

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

 Logger GetLogger(string category) void SetLevel(string category, int level) void SetLevelForAll(int level) void FilterAddID(int id) void FilterRemoveID(int id) 

दूसरा वर्ग, जो बाहर से दिखाई देता है, लॉगलेवल है। टेलीकॉम से मैंने जो अर्थ निकाले हैं। फिर मैंने NLog को सरल बनाने का फैसला किया, और सामान्य इंट का उपयोग एक स्तर के रूप में किया, ताकि तुलना के स्तर के साथ समझदार न हो, आदि।
उन्होंने डिबग के दो स्तरों को छोटा और विस्तृत बनाने के लिए केवल सभी स्तर को जोड़ा, जो कभी-कभी अभ्यास में कमी थी।

  public const int Invalid = 0; public const int Always = 1; public const int Fatal = 2; public const int Error = 3; public const int Warning = 4; public const int Info = 5; public const int Event = 6; public const int Debug = 7; public const int All = 8; public const int Total = 9; 

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

 public interface Logger { /// <summary> /// Method for unrecoverable errors. /// </summary> /// <param name="message"></param> /// <param name="ex"></param> void Fatal(string message, Exception ex = null); /// <summary> /// Method for external errors, such as user input or file access. /// </summary> /// <param name="message"></param> /// <param name="id"></param> /// <param name="ex"></param> void Warning(string message, int id = 0, Exception ex = null); /// <summary> /// Method for regular debug logging. /// </summary> /// <param name="message"></param> /// <param name="id"></param> void Debug(string message, int id = null); } 

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

  class CheckingLogger : InternalLogger { bool[] levels = new bool[LogLevel.Total]; Sender send; string category; public CheckingLogger(string category, Sender sender, int level) { this.send = sender; this.category = category; SetLevel(level); } public void SetLevel(int level) { for (int n = LogLevel.Fatal; n < LogLevel.Total; n++) { levels[n] = (n <= level); } } public void Error(string message, Exception ex = null) { if (levels[LogLevel.Error]) { send(new LogItem(category, LogLevel.Error, message, ex: ex)); } } 

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

  struct LogItem { public readonly String category; public readonly String message; public readonly int[] ids; public readonly int level; public readonly Exception ex; public readonly DateTime time; } 

निर्भरता इंजेक्शन

इस खंड में, मैं एक IoC कंटेनर का उपयोग करने का एक उदाहरण दूंगा। अगली पंक्ति में लकड़हारा वर्ग है। नाम IoC कंटेनर से जुड़ा नहीं है, यह सिर्फ मेल खाता है। यह GetLogger विधि प्रदान करता है, जहाँ LogAccess वर्ग विधि अनुमानित है। कोड में टिप्पणियों को देखते हुए, NLog, गारंटी नहीं देता कि एक ही श्रेणी के साथ GetLogger विधि नामक दो बार एक ही लकड़हारा उदाहरण देगा। मैंने सोचा और तय किया कि यह तरीका अड़चन नहीं होगा, और इस पर सामान्य सिंक्रनाइज़ेशन सेट करें, इस मामले में उदाहरण की गारंटी दी जानी चाहिए। लॉग कंटेनर सभी पहले से तैयार किए गए लॉगर को स्टोर करता है और उन्हें एक सेटलेवल वितरित करता है, जो लॉगऑक से अनुमानित भी है।
इसलिए, हम एक IoC कंटेनर बनाते हैं, आगे की कॉन्फ़िगरेशन को निम्नलिखित दो लाइनों के बीच रखा गया है:

 var builder = new ContainerBuilder(); IContainer container = builder.Build(); 

ऊपर से, यह स्पष्ट है कि वर्ग एक सिंगलटन होना चाहिए। यह काफी सरलता से हासिल किया गया है:

  builder .RegisterType<LoggerContainer>() .SingleInstance(); 

और अगली विधि, हम अपने सिंगलटन के लिए एक लिंक प्राप्त कर सकते हैं।

  Container .Resolve<LoggerContainer>(); 

ताकि लॉग कंटेनर खुद IoC कंटेनर की सेवाओं का उपयोग कर सके, जहां से इसे बनाया गया था, मैंने कंस्ट्रक्टर में इसे IComponentContext पैरामीटर जोड़ा। यह आपको बाहर की कक्षा का निर्माण करने और विशिष्ट कक्षाओं को बदलने की अनुमति देता है, उदाहरण के लिए, विस्तारित कार्यक्षमता वाले कक्षाओं में, उपयोग किए गए कोड को बदले बिना, लेकिन केवल कॉन्फ़िगरेशन को बदलकर, सहित कोड में बिल्कुल सेट नहीं करना संभव है, लेकिन xml से लोड करना है। दरअसल, बाहरी निर्माण के साथ आंतरिक निर्माण के इस प्रतिस्थापन को निर्भरता का कार्यान्वयन कहा जाता है। दरअसल, एक विधि जो संदर्भ से एक विशिष्ट लकड़हारा प्राप्त करती है:

 private InternalLogger CreateLogger(string category) { return context .Resolve<InternalLogger>(new NamedParameter[]{ new NamedParameter("category", category), new NamedParameter("level",LogLevel.Default) }); } 

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

  builder .RegisterType<CheckingLogger>() .As<InternalLogger>(); 

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

  [TestClass()] public class LoggerContainerTest { IContainer testContainer; public LoggerContainerTest() { var builder = new ContainerBuilder(); builder .Register<LoggerContainer>((c, p) => new LoggerContainer(c.Resolve<IComponentContext>())); builder .RegisterType<LoggerMock>() .As<InternalLogger>(); testContainer = builder.Build(); } 

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

  LoggerContainer lc= testContainer .Resolve<LoggerContainer>(); var logger1 = lc.GetLogger(cat1); var logger2 = lc.GetLogger(cat2); var logger3 = lc.GetLogger(cat1); Assert.AreEqual(logger1, logger3); Assert.AreNotEqual(logger1, logger2); 

Moq टेस्ट फ्रेमवर्क

एक और उपयोगी तकनीक जो लेखन परीक्षणों को आसान बनाती है। मैं इसके आवेदन को निम्न वर्ग के उदाहरण पर दिखाऊंगा, जिसे मैंने एक लकड़हारा या LogCollector कहा था। यह स्ट्रीम भेजने के साथ डीकोपिंग के लिए उसी IQueued का उपयोग करता है, पहचानकर्ता द्वारा फ़िल्टरिंग करता है, और दूसरी निर्भरता में एक वर्ग होता है जो एक फाइल पर लिखता है और घूमता है।
मैं विस्तार से वर्णन नहीं करूंगा कि यह कैसे काम करता है, सब कुछ काफी सरल और स्पष्ट है, मैं एक अन्य वर्ग पर सामान्य शब्दों में लिखूंगा, जो एक फ़ाइल पर लिखने से पहले, LogItem से एक स्ट्रिंग का निर्माण करता है। मैंने इसे कॉन्फ़िगर करने योग्य बनाने का फैसला किया, इस तरह की समस्या को हल करने के लिए लंबे समय से दिलचस्प है।
NLog कॉन्फ़िगरेशन उदाहरण: लेआउट = "$ {longdate} $ {अपरकेस: $ {स्तर}} $ {संदेश}"।
और मेरे लकड़हारे LogMessageFormat = \ d \ l \ m \ r \ n का कॉन्फ़िगरेशन उदाहरण।
यह बिल्कुल उसी रूप, दिनांक, स्तर, संदेश और लाइन फ़ीड में प्रदर्शित होता है। विशेष रूप से अनुकूलित आउटपुट प्रारूप ताकि आप सीधे प्रदर्शन की तुलना कर सकें। इसके अलावा, यह इस पंक्ति में था कि मैंने इन सभी पहचानकर्ताओं के बीच एक पहचानकर्ता, इसके स्टैक ट्रेस के साथ एक अपवाद और, अच्छी तरह से, मनमानी लाइनों को जोड़ना संभव बना दिया। निर्माण एक श्रृंखला में आगे बढ़ता है, प्रत्येक बाद का कंस्ट्रक्टर संदेश के अपने हिस्से को संचारित LogItem से StringBuilder में फेंकता है। मास्टर स्ट्रिंग को पार्स करते समय चेन एक बार बनती है।
कक्षा का मुख्य कार्य काफी सरल है, इसलिए मैं उस कोड को नहीं दूंगा जो इसे लागू करता है, मैं फ़िल्टरिंग पर थोड़ा ध्यान केंद्रित करूंगा। चूंकि एक सिंक्रनाइज़ेशन कार्य भी है, अर्थात, एक पहचानकर्ता को जोड़ने या हटाने वाला एक विधि कॉल दूसरे धागे से आता है। एक तरीका है - सूची को ब्लॉक करने के लिए, अच्छी तरह से, या हाशसेट, प्रदर्शन को प्रभावित करेगा। मैंने थोड़ा अलग रास्ता अपनाया, मैंने भी लंबे समय से इस तरह के अवसर को भाषा द्वारा प्रदान किया था और इसके लिए एक उपयोग खोजना चाहता था। समाधान का सार एक गैर-अवरुद्ध कतार के माध्यम से एक अनाम एक्शन विधि पारित करना है। filterQue = नया समवर्ती queueue <Action <HashSet >> ();
प्रत्येक फ़िल्टरिंग प्रयास में, फ़िल्टरिंग विधि यह जांचती है कि क्या कतार खाली है, जिसे मॉनिटर को कैप्चर करने की तुलना में तेजी से काम करना चाहिए, और यदि यह खाली नहीं है, तो यह लॉगर स्ट्रीम के संदर्भ में विधि को निष्पादित करता है।

  Action<HashSet<int>> refresh; while (!filterQue.IsEmpty) { if (filterQue.TryDequeue(out refresh) && refresh != null) { refresh(filter); } } 

कॉलिंग विधि, सेट को सीधे एक्सेस करने के बजाय, वांछित प्रतिनिधि को कतार में रखती है।

  filterQue.Enqueue((x)=> { x.Add(id); }); 

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

 [assembly: System.Runtime.CompilerServices.InternalsVisibleTo("LoggerTest"), System.Runtime.CompilerServices.InternalsVisibleTo("DynamicProxyGenAssembly2")] 

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

  LogItem message = new LogItem(category, level, msg, ids, GetException()); var qThread = new Mock<IQueued<LogItem>>(MockBehavior.Strict); var writer = new Mock<ILogWriter>(MockBehavior.Strict); qThread .Setup(s => s.Send(It.IsAny<LogItem>())); writer .Setup(s => s.GetTimeout()) .Returns(timeout); qThread .Setup(s => s.SetTimeout(It.IsAny<int>())); LogCollector target = new LogCollector(qThread.Object, writer.Object); qThread .Verify(s => s.SetTimeout(It.Is<int>(a => a == timeout))); target.Send(message); qThread .Verify(s => s.Send(It.Is<LogItem>(i => i.Equals(message))), Times.Once()); } 

मामले में स्पष्टीकरण की आवश्यकता है: पहली दो पंक्तियां उनके द्वारा निर्भरता के tattors द्वारा बनाई गई हैं। सख्त पैरामीटर का मतलब है कि मोक एक अपवाद फेंक देगा यदि कक्षाएं उपयोग करने से पहले कॉन्फ़िगर नहीं किए गए तरीकों को कॉल करती हैं, जिससे परीक्षण फ़्लिप हो जाता है।
अगली कॉल में IQueued मॉक की विधि भेजें, यह दर्शाता है कि यह परीक्षण के दौरान बुलाया जाएगा। यहां आप पूर्व-शर्तें भी निर्दिष्ट कर सकते हैं, यदि कई विधियाँ हैं, तो परीक्षण के बाद आप VerifyAll () पर कॉल करके सभी पूर्व शर्त जाँच सकते हैं। मैं परीक्षण का एक विस्तृत, निरर्थक विवरण पर बस गया। अगली पंक्ति का मतलब है कि गेटटाइमआउट विधि को बुलाया जाना चाहिए, और मोकू को यह भी इंगित करता है कि इसे वापस लौटना चाहिए। अगली पंक्ति भी SetTimeout पद्धति को चिह्नित करती है।
अगला, हम कलेक्टर ऑब्जेक्ट बनाते हैं, और इसे इसकी निर्भरता खिलाते हैं, जिसके बाद हम यह सुनिश्चित करते हैं कि कलेक्टर ने एक निर्भरता पर गेटटाइमआउट कहा और मूल्य को दूसरी निर्भरता के लिए पारित कर दिया। कंस्ट्रक्टर के परीक्षण के लिए एक अलग परीक्षण विधि बनाना बेहतर था, लेकिन मैंने इसे बिना किसी कारण के, अनायास छोड़ दिया। इसके बाद, हम एक संदेश भेजते हैं, और यह सुनिश्चित करते हैं कि इसे डोनेशन के लिए भेज दिया गया है।
यह पहले से ही देखा जा सकता है कि परीक्षण कोड पूरा हो गया है, और मैन्युअल रूप से घोषित मोक के साथ अतिरिक्त फ़ाइलों को देखने के लिए एक समीक्षा या रीडिज़ाइन को बाध्य नहीं करता है, लेकिन यह संभावित समय लागत को कम करता है, जो अपने आप में Moq का उपयोग करने के लिए एक अच्छा पर्याप्त कारण है।

लोड परीक्षण

मुझे NLog पर अपने दृष्टिकोण की श्रेष्ठता को देखने की उम्मीद थी, मैं माइक्रोपोप्टिइम्यूएशन पर ध्यान देने के लिए तैयार था, अपेक्षाओं को थोड़ा बेहतर ढंग से पूरा करने के लिए एक पैसा बचा सकता था। लेकिन बहुत पहले परीक्षणों के परिणामों ने मुझे मारा, ऐसी इच्छा को दोहराते हुए।
लोड परीक्षण के लिए, मैंने एक कंसोल एप्लिकेशन बनाया, जिसमें मैंने एक लकड़हारा लिया और उसे लूप में संदेश भेजे।

 var log = SharpLogger.LogAccess.GetLogger("flooder " + tid); foreach (var x in Enumerable.Range(0, messageCount)) { log.Info("Message", x); if (x % 1000 == 0) Thread.Sleep(0); } 

और NLog के लिए एक ही विधि।

  var log = NLog.LogManager.GetLogger("flooder " + tid); foreach (var x in Enumerable.Range(0, messageCount)) { log.Info("Message"); if (x % 1000 == 0) Thread.Sleep(0); } 

विधि में एक tid दिखाई देता है, जिसका अर्थ है कि निष्पादन कई थ्रेड्स में होता है।
बेशक, मैंने बहुत सारे परीक्षण किए, लेकिन मुझे लगता है कि यह एक परीक्षण लाने के लिए काफी पर्याप्त है। तीन धाराएँ प्रत्येक में 200 हज़ार संदेश भेजती हैं। टास्क मैनेजर के स्क्रीनशॉट में, प्रोसेसर लोड हो रहा है। पहला छोटा फट मेरा लकड़हारा है, फिर, 5 सेकंड की देरी के बाद, NLog काम करता है। परिणामी लॉगफ़ाइल्स समान रूप से बदल गई, बेमेल समय के अपवाद के साथ।

मैं परीक्षण कार्यक्रम द्वारा माप का एक आत्म-व्याख्यात्मक परिणाम भी दूंगा।

जब x64 के तहत recompiling, परिणाम लगभग अपरिवर्तित है।

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

परिणाम जो कार्यक्रम दिया गया है वह 7.15 सेकंड है। लेकिन ग्राफ़ से पता चलता है कि फ़ाइल को लिखने के लिए लकड़हारा स्ट्रीम ने लगभग 25 सेकंड के लिए काम किया। यह निस्संदेह एक खामी है, क्योंकि प्रोग्राम पूरी तरह से लॉगऑनर से पहले समाप्त हो सकता है, पूर्ण रिकॉर्डिंग से पहले, जिसे एनलॉग के मामले में बाहर रखा गया है और इसके अलावा, मुख्य कार्यक्रम में लोड होने पर भी थ्रेड में एक प्रोसेसर पूरी तरह से होगा। यहाँ आराम देने वाली बात यह है कि इस तरह के कई लॉग्स के साथ एनओलोग अनुमानित अनुमान के अनुसार छह घंटे तक प्रोसेसर को मार देगा, जो इस खामी के साथ सामंजस्य स्थापित करने का कारण बनता है।
और एक और बात जिसका उल्लेख किया जाना चाहिए वह है अवरुद्ध के साथ एक नियमित कतार के सापेक्ष प्रदर्शन पर गैर-अवरुद्ध कतार का प्रभाव।
उन्होंने दो परीक्षण किए, पहली 3 धाराओं में उन्होंने प्रत्येक में 15 मिलियन संदेश भेजे, एक गैर-अवरुद्ध कतार ने मापा समय को 22.2 सेकंड से घटाकर 17.8 कर दिया। थ्रेड्स की संख्या में 30 तक की वृद्धि के साथ, और संदेशों की कुल संख्या को बनाए रखते हुए, यानी 1.5 मिलियन प्रति स्ट्रीम, अवरुद्ध कतार ने परीक्षण को थोड़ा धीमा करके 23.7 सेकंड कर दिया, जबकि गैर-अवरुद्ध, इसके विपरीत, 17.4 तक थोड़ा सा बढ़ गया, जिससे अंतराल बढ़ गया।
जैसा कि स्क्रीनशॉट से देखा जा सकता है, परीक्षण 4 कोर i5 पर 4 गीगाहर्ट्ज की आवृत्ति के साथ विंडोज़ 8 पर किया गया था

। परियोजना को जीथब से https://github.com/repinvv/Sharpogger
त्रुटियों, टाइपोस और अन्य टिप्पणियों - वेलकम में डाउनलोड किया जा सकता है ।