परीक्षण मल्टीथ्रेडेड और एसिंक्रोनस कोड

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

मूल लेख से सबसे महत्वपूर्ण कोड टिप्पणियों के लिए shalomman , schroeder और FTOH का धन्यवाद।

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

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

हम समानांतर चलते हैं

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

messageBus.registerHandler(message - > { System.out.println("Received " + message); }); messageBus.publish("test"); 

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

 String msg = "test"; messageBus.registerHandler(message -> { System.out.println("Received " + message); assertEquals(message, msg); }; messageBus.publish(msg); 

यह बेहतर लग रहा है। हम अपना परीक्षण चलाते हैं और यह हरा है। कूल! लेकिन प्राप्त संदेश कहीं भी मुद्रित नहीं था, कहीं न कहीं कुछ गलत था।

एक सेकंड रुकिए

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

 String msg = "test"; messageBus.registerHandler(message -> { System.out.println("Received " + message); assertEquals(message, msg); }; messageBus.publish(msg); Thread.sleep(1000); 

हमारा परीक्षण हरा है और प्राप्त अभिव्यक्ति अपेक्षित रूप से मुद्रित है। कूल! लेकिन नींद के एक सेकंड का मतलब है कि हमारा परीक्षण कम से कम एक सेकंड के लिए किया जाता है, और इसमें कुछ भी अच्छा नहीं है। हम सोने का समय कम कर सकते हैं, लेकिन फिर हम संदेश प्राप्त करने से पहले परीक्षण पूरा करने का जोखिम उठाते हैं। हमें मुख्य परीक्षण थ्रेड और संदेश हैंडलर थ्रेड के बीच समन्वय करने का एक तरीका चाहिए। Java.util.concurrent पैकेज को देखते हुए, हम निश्चित हैं कि हम क्या उपयोग कर सकते हैं। CountDownLatch के बारे में क्या?

 String msg = "test"; CountDownLatch latch = new CountDownLatch(1); messageBus.registerHandler(message -> { System.out.println("Received " + message); assertEquals(message, msg); latch.countDown(); }; messageBus.publish(msg); latch.await(); 

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

इतना खुश?

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

 latch.await(1, TimeUnit.SECONDS); 

एक परीक्षण जो ब्लॉक किया गया है वह TimeoutException अपवाद के साथ 1 सेकंड के बाद विफल हो जाता है। अंत में, हम समस्या को ढूंढेंगे और परीक्षण को ठीक करेंगे, लेकिन समय-समय पर जगह छोड़ने का निर्णय लेंगे। यदि यह फिर से होता है, तो हम अपने परीक्षण को एक दूसरे और क्रैश के लिए लॉक करना पसंद करेंगे, हमेशा के लिए ब्लॉक करने और बिल्कुल भी पूरा नहीं होने के लिए।
परीक्षण लिखते समय एक और समस्या हमें दिखाई देती है कि वे सभी तब भी पास होने लगती हैं जब उन्हें शायद नहीं करना चाहिए। यह कैसे संभव है? संदेश प्रसंस्करण परीक्षण पर फिर से विचार करें:

 messageBus.registerHandler(message -> { assertEquals(message, msg); latch.countDown(); }; 

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

 CountDownLatch latch = new CountDownLatch(1); new Thread(() -> { assertTrue(false); latch.countDown(); }).start(); latch.await(); 

परीक्षण हरा है! तो अब हम क्या करें? हमें संदेश हैंडलर स्ट्रीम से किसी भी परीक्षण त्रुटियों को मुख्य परीक्षण स्ट्रीम में भेजने का एक तरीका चाहिए। यदि संदेश हैंडलर थ्रेड में कोई विफलता होती है, तो हमें मुख्य थ्रेड में पुन: प्रकट करने की आवश्यकता होती है ताकि परीक्षण फ़्लिप हो जाए, जैसा कि अपेक्षित था। आइए इसे करने का प्रयास करें:

 CountDownLatch latch = new CountDownLatch(1); AtomicReference<AssertionError> failure = new AtomicReference<>(); new Thread(() -> { try { assertTrue(false); } catch (AssertionError e) { failure.set(e); } latch.countDown(); }).start(); latch.await(); if (failure.get() != null) throw failure.get(); 

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

कचरा काटो

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

 String msg = "test"; Waiter waiter = new Waiter(); messageBus.registerHandler(message -> { waiter.assertEquals(message, msg); waiter.resume(); }; messageBus.publish(msg); waiter.await(1, TimeUnit.SECONDS); 

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

और भी समानांतर

अब जब हम प्रमाणित बहु-थ्रेडेड परीक्षक बन गए हैं, तो हम यह पुष्टि करना चाहते हैं कि कई अतुल्यकालिक क्रियाएं हो रही हैं। समवर्तीUnit की वेटर यह सरल बनाता है:

 Waiter waiter = new Waiter(); messageBus.registerHandler(message -> { waiter.resume(); }; messageBus.publish("one"); messageBus.publish("two"); waiter.await(1, TimeUnit.SECONDS, 2); 

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

सारांश

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

@Middle_java द्वारा अनुवादित