वितरित सिस्टम का परीक्षण करने के लिए नेटवर्क त्रुटियां बनाएं

Question

मैं HTTP के माध्यम से संचार के लिए जावा लाइब्रेरी विकसित कर रहा हूं, और मैं पैकेट नुकसान, उच्च विलंबता, कम बैंडविड्थ और भीड़ जैसी नेटवर्क समस्याओं के मामले में इसकी विश्वसनीयता और प्रदर्शन का परीक्षण करना चाहता हूं। मैं क्लाइंट साइड से कनेक्शन करने के लिए Apache's httpclient library का उपयोग कर रहा हूं, और जावा सर्वर के com.sun.net.httpserver.Http सर्वर को सर्वर सर्वर शुरू करने के लिए उपयोग कर रहा हूं।

क्या पुस्तकालय उपलब्ध हैं जो उस तरह की चीज करते हैं, या मुझे अपना खुद का रोल करना चाहिए? मुझे लगता है कि मैं अपने स्वयं के org.apache.http.conn.scheme.SchemeSocketFactory को क्लाइंट पक्ष में प्लग करने का प्रयास कर सकता हूं, और इसके साथ ऊपर वर्णित कई समस्याओं का अनुकरण कर सकता हूं, लेकिन मैं पहले से काम करने वाली कुछ चीज़ों का उपयोग करना पसंद करूंगा :-)

यह Creating TCP network errors for unit testing पर सवाल के समान है, लेकिन मैं जावा पर लिनक्स से जुड़े समाधान ढूंढ रहा हूं। मैंने क्लिक पर देखा है, जिसे उस प्रश्न के लिए सुझाया गया था, लेकिन मुझे यकीन नहीं है कि यह जो मैं ढूंढ रहा हूं उसे प्रदान कर सकता हूं।

Answer 1

चूंकि जावा एपीआई के पास निम्न स्तर के नेटवर्क एपीआई तक पहुंच नहीं है, यह अनुकरण करना चुनौतीपूर्ण होगा।

वैकल्पिक रूप से अपाचे HTTP कोर घटक लाइब्रेरी में विलंबता और डेटा हानि और संभावित रूप से बैंडविड्थ मुद्दों को अनुकरण करने में आपकी सहायता करने के लिए कुछ हो सकता है। लाइब्रेरी में आपके स्वयं के सत्र इनपुट और आउटपुट बफर इंजेक्ट करने की सुविधा है। आप Advanced Features of HTTP Core

पर दस्तावेज़ीकरण देख सकते हैं अपने खुद के बफर इंजेक्शन लगाने के द्वारा

• विलंबता पढ़ने में इंजेक्शन थोड़ा विलंब हो सकता है और लिखते हैं
• डेटा हानि कुछ बाइट्स फेंक दिया है सकते हैं। यह वास्तविक अर्थ में पैकेट नुकसान नहीं है, क्योंकि डुप्लिकेट का कोई पुनर्विक्रय नहीं है।
• बैंडविड्थ को पढ़ने/लिखने और फ्लश ऑपरेशंस को ट्यून करके सीमित किया जा सकता है।
• ट्रैफिक को पढ़ना और बफर को लिखने की सभी मंदी के अलावा अनुकरण करना मुश्किल है।

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

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

आशा है कि यह सहायक होगा।

Answer 2

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

Answer 3

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

mockito जैसे कुछ का उपयोग करना, या यदि PowerMock की आवश्यकता है, तो आप लाइब्रेरी को अपवादों को फेंकने के लिए बता सकते हैं जब आपके द्वारा बुलाई गई विधि का आह्वान किया जाता है।

उदाहरण:

import static org.mockito.Mockito.mock 
import static org.mockito.Mockito.when 
... 
@Test(expected=HttpException.class) 
public void invockationThrowsHttpException() { 
    ... 
    HttpClient httpClient = mock(HttpClient.class) 
    when(httpClient).executeMethod(args...).thenThrow(HttpException...) 

    underTest.invokeCodeUnderTest(args...) 
    ... 
} 

ऊपर के उदाहरण JUnit4 मान लिया गया है। मॉकिटो वेबसाइट पर एक बहुत अच्छा ट्यूटोरियल है। पावरमोक का उपयोग तब किया जाता है जब आपको उन चीज़ों का नकल करने की आवश्यकता होती है जो मॉकिटो नकली नहीं है (उदाहरण के लिए स्थिर या अंतिम विधियां)।

एक तरफ मैंने देखा कि अपाचे का HTTP क्लाइंट जीवन के अंत में है और वे इसके बजाय अपाचे HTTP घटक पर स्विच करने की अनुशंसा करते हैं। यदि आपकी परियोजना अभी भी शुरुआती चरणों में है तो यह अब स्विचिंग के लायक हो सकती है।