👵🏿 👩🏽‍💼 🥣 जब सार्वजनिक विधि के माध्यम से परीक्षण से बदबू आने लगती है (उदाहरण) 👾 👩🏼‍🚒 👸🏼

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

स्टॉक उदाहरण

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

आप ध्वज का कार्यान्वयन और परीक्षण कैसे करेंगे?

using System; using System.Threading.Tasks; using System.Threading; using System.Messaging; namespace PublicMethodNottrivialSample { public class MessageProcessorService { private object _lockObject = new object(); private CancellationTokenSource _cancellationSource; private Action _receiveMessage; private int _listenerThreads = 5; public void Start() { lock (_lockObject) { _cancellationSource = new CancellationTokenSource(); Task.Factory.StartNew(() => InitializeReceiveLoop(_cancellationSource.Token), _cancellationSource.Token); } } private void InitializeReceiveLoop(CancellationToken cancellationToken) { _receiveMessage = () => { while (!cancellationToken.IsCancellationRequested) { using (MessageQueueTransaction msgTx = new MessageQueueTransaction()) { try { msgTx.Begin(); //   MessageQueue queue = new MessageQueue(); Message message = queue.Receive(msgTx); //    ,    if (!cancellationToken.IsCancellationRequested) { ProcessMessage(message); } msgTx.Commit(); } catch (Exception ex) { // some logging } } } }; for (int n = 0; n < _listenerThreads; n++) { StartProcessingLoop(cancellationToken); } } private void ProcessMessage(Message message) { //   ,     } private void StartProcessingLoop(CancellationToken cancellationToken) { Task.Factory.StartNew(_receiveMessage, cancellationToken); } } }

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

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

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

"आप चेकर्स, या जाओ"

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

निजी पद्धति का परीक्षण किया जा सकता है
विधि को सार्वजनिक किया जा सकता है
आंतरिक बनाया जा सकता है
सार्वजनिक विधि के रूप में एक अलग वर्ग में खींचा जा सकता है

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

यदि विधि को समाधान में कहीं से भी चलाया जा सकता है और यह कक्षा के व्यवहार का हिस्सा है, तो इसे सार्वजनिक करें और इसे क्लास इंटरफ़ेस में खींचें;
यदि विधि का उपयोग किसी अन्य वर्ग से किया जा सकता है, लेकिन केवल इस विधानसभा के अंदर, तो इसे आंतरिक करें ;
यदि विधि का उपयोग केवल मुख्य वर्ग के अंदर ही किया जा सकता है, जहां इसे किसी अन्य विधि से बुलाया जा सकता है, तो इसे आंतरिक संरक्षित करें ।

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

परीक्षण प्रक्रियाप्रक्रिया

आइए कार्य पर वापस जाएं। उपरोक्त दृष्टिकोण के बाद, मैं कुछ बदलाव करूंगा:

ProcessMessage को सार्वजनिक करेगा
फ्लैग लॉजिक के लिए एक नई संरक्षित आंतरिक विधि तैयार करेगा (उदा। GetFlagValue)
सभी मामलों के लिए GetFlagValue के लिए परीक्षण लिखेंगे
मैं यह सुनिश्चित करने के लिए ProcessMessage के लिए एक परीक्षण लिखूंगा कि GetFlagValue का उपयोग सही तरीके से किया जाता है: पैरामीटर सही तरीके से पारित किए जाते हैं और यह वास्तव में उपयोग किया जाता है

मैं स्पष्ट कर दूंगा कि मैं ProcessMessage पद्धति में GetFlagValue के उपयोग के सभी मामलों के लिए इकाई परीक्षण नहीं लिखूंगा, बशर्ते कि मैंने GetFlagValue इकाई परीक्षणों में इन मामलों का परीक्षण किया हो। अनियोजित मामलों के मामले में, उन्हें जोड़ा जाना चाहिए। इस मामले में, मुख्य दृष्टिकोण बना हुआ है:

सभी मामलों को GetFlagValue इकाई परीक्षणों द्वारा कवर किया गया है
ProcessMessage इकाई परीक्षण सत्यापित करते हैं कि ध्वज विधि का सही उपयोग किया गया है

मेरा मानना है कि इसके अनुसार, आप ProcessMessage के लिए केवल एक इकाई परीक्षण और GetFlagValue के लिए कई लिख सकते हैं।

कुछ इस तरह। आपकी राय

जब सार्वजनिक विधि के माध्यम से परीक्षण से बदबू आने लगती है (उदाहरण)

स्टॉक उदाहरण

"आप चेकर्स, या जाओ"

परीक्षण प्रक्रियाप्रक्रिया

More articles: