जावा डेवलपर्स के लिए विन्यास परीक्षण: व्यावहारिक अनुभव

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

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

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


मेरा नाम रुस्लान है, मैं ड्यूश बैंक के लिए काम करता हूं। हम इसके साथ शुरू करते हैं:



बहुत पाठ है, दूर से ऐसा लग सकता है कि यह रूसी है। लेकिन यह सच नहीं है। यह बहुत प्राचीन और खतरनाक भाषा है। मैंने सरल रूसी में अनुवाद किया:

• सभी पात्र बने हैं
• सावधानी के साथ प्रयोग करें
• अपने खर्च पर अंतिम संस्कार किया

मैं संक्षेप में वर्णन करूंगा कि मैं आज किस बारे में बात करने जा रहा हूं। मान लीजिए कि हमारे पास एक कोड है:



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

इसलिए, हमारे महत्वपूर्ण कोड के लिए, हमारे पास परीक्षण हैं:



सहसा वहाँ। अब, शायद, लगभग सभी के पास है। परीक्षण सत्यापित करते हैं कि कोड सही समस्या को हल करता है और सही पैसे बनाता है। लेकिन सेवा कोड तक सीमित नहीं है, और कोड के बगल में एक कॉन्फ़िगरेशन भी है:



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

परीक्षण करने के लिए कॉन्फ़िगरेशन महत्वपूर्ण क्यों है?

यहां यह चाल है: कॉन्फ़िगरेशन नुकसान प्रोग्राम निष्पादन में त्रुटियां कोड में त्रुटियों से कम नहीं हैं। वे भी, गलत कार्य करने के लिए कोड का कारण बन सकते हैं - और ऊपर देखें।

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

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

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

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

आखिरकार मैंने कहा - ऐसा लगता है कि परीक्षण विन्यास एक गर्म विषय होना चाहिए। लेकिन व्यवहार में यह कुछ इस तरह दिखता है:



कम से कम हमारे साथ ऐसा ही था - एक निश्चित बिंदु तक। और मेरी रिपोर्ट के कार्यों में से एक यह है कि आप के लिए भी इस तरह दिखना बंद कर दें। मुझे उम्मीद है कि मैं आपको इस ओर धकेल सकूंगा।

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

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

रिपोर्ट की सामान्य रूपरेखा:

• "सोमवार दोपहर से पहले आप क्या कर सकते हैं": सरल, उपयोगी उदाहरण।
• "सोमवार, दो साल बाद": जहां और कैसे बेहतर करना है।
• कॉन्फ़िगरेशन को फिर से तैयार करने के लिए समर्थन: घने कवरेज कैसे प्राप्त करें; सॉफ्टवेयर विन्यास मॉडल।

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

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

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

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

भाग 1. "आप इसे उस तरह कर सकते हैं"

अब यह समझना मुश्किल है कि हमारे साथ पहला कॉन्फ़िगरेशन परीक्षण क्या था। आंद्रेई हॉल में बैठे हैं, वह कह सकते हैं कि मैंने झूठ बोला। लेकिन यह मुझे लगता है कि यह सब इस के साथ शुरू हुआ:



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

इस समस्या को कई लाइनों में हल किया जाता है। यह परीक्षण, जो (मुझे ऐसा लगता है) हमारा पहला था, इस तरह देखा गया:



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

जब मैंने इसे देखा तो मेरी पहली प्रतिक्रिया मिश्रित थी:



पहली छाप: यह मेरी सुंदर इकाई परीक्षणों में क्या है? हम फाइल सिस्टम में क्यों चढ़ गए?

और फिर आश्चर्य आया: "क्या हो सकता है?"

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



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

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

एक और परीक्षा उदाहरण। हम यहाँ क्या जाँच कर रहे हैं?



वह जाँचता है कि असली पासवर्ड उत्पादन में लीक नहीं हुआ है। सभी पासवर्ड कुछ इस तरह दिखना चाहिए:



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

... और इन परीक्षणों के पर्याप्त रूप से लिखने के बाद, एक दिलचस्प सवाल सामने आता है: हम विन्यास से क्या मतलब है, इसकी सीमा कहां है? हम संपत्ति-फ़ाइल को कॉन्फ़िगरेशन के रूप में मानते हैं, हमने इसे कवर किया है - और क्या एक ही शैली में कवर किया जा सकता है?

एक कॉन्फ़िगरेशन पर विचार करने के लिए क्या

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

उदाहरण के लिए, हमारे पास SQL ​​पैच की एक प्रणाली है जो तैनाती प्रक्रिया के दौरान डेटाबेस पर लुढ़का हुआ है।



वे SQL * प्लस के लिए लिखे गए हैं। एसक्यूएल * प्लस 60 के दशक से एक उपकरण है, और इसमें सभी प्रकार की अजीब चीजों की आवश्यकता होती है: उदाहरण के लिए, यह सुनिश्चित करने के लिए कि फ़ाइल का अंत एक नई लाइन पर है। बेशक, लोग नियमित रूप से लाइन के अंत को वहां रखना भूल जाते हैं, क्योंकि वे 60 के दशक में पैदा नहीं हुए थे।



और फिर से इसे एक ही दर्जन लाइनों द्वारा हल किया जाता है: हम सभी एसक्यूएल फ़ाइलों का चयन करते हैं, जांचें कि अंत में एक अनुगामी स्लैश है। सरल, सुविधाजनक, तेज।

"एक पाठ फ़ाइल की तरह" का एक अन्य उदाहरण crontabs है। हमारी crontab सेवाएं शुरू और बंद हो जाती हैं। वे अक्सर दो त्रुटियों का कारण बनते हैं:



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

दूसरे, पिछले उदाहरण की तरह, फ़ाइल का अंत भी एक नई लाइन पर होना चाहिए।

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

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

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



उदाहरण के लिए, जाँच करें कि JAVA_HOME प्रत्येक वातावरण में स्थापित है, या कि कुछ jini पुस्तकालय है जो हम LD_LIBRARY_PATH में उपयोग करते हैं। किसी तरह हम जावा के एक संस्करण से दूसरे संस्करण में चले गए, और परीक्षण का विस्तार किया: हमने जाँच की कि JAVA_HOME में एनवायरनमेंट के उस सबसे उपसमुच्चय पर "1.8" शामिल है, जिसे हमने धीरे-धीरे नए संस्करण में स्थानांतरित कर दिया।

यहाँ कुछ उदाहरण हैं। मुझे निष्कर्ष के पहले भाग को संक्षेप में प्रस्तुत करना चाहिए:

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

भाग 2. अधिक जटिल मामले

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

इसका क्या मतलब है "कठिन"? जिन परीक्षणों का मैंने वर्णन किया है उनमें लगभग निम्नलिखित संरचना है:



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

• UI एप्लिकेशन इसके वातावरण के सर्वर से कनेक्ट होता है।
• एक ही वातावरण की सभी सेवाएँ एक ही प्रबंधन सर्वर से जुड़ती हैं।
• एक ही वातावरण में सभी सेवाएँ समान डेटाबेस का उपयोग करती हैं ।

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

या सभी सेवाएं एक ही डेटाबेस, एक ही चीज का उपयोग करती हैं - विभिन्न मॉड्यूल में सेवाएं।

वास्तव में, ऐसी तस्वीर है: बहुत सारी सेवाएं, उनमें से प्रत्येक की अपनी कॉन्फ़िगरेशन संरचना है, आपको उनमें से कुछ को कम करने और चौराहे पर कुछ जांचने की आवश्यकता है:



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

यदि आप सपने देखते हैं, तो यह अधिक सुविधाजनक होगा, फिर मैंने सपना देखा कि परीक्षण ऐसा लगेगा जैसे मैं इसे मानव भाषा में समझाता हूं:

@Theory public void eachEnvironmentIsXXX( Environment environment ) { for( Server server : environment.servers() ) { for( Service service : server.services() ) { Properties config = buildConfigFor( environment, server, service ); //… check {something} about config } } } 

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



हमें इस बात की आवश्यकता है कि एप्लिकेशन को कैसे लागू किया जाए, इस तक पहुंचने के लिए कोड से एक अवसर प्राप्त होता है: इस डेटा संरचना को प्राप्त करने के लिए किस सर्वर पर कौन-कौन सी सेवाएँ, किस-किस वातावरण में हैं। और इससे आगे बढ़ते हुए, मैं कॉन्फ़िगरेशन को लोड करना और इसे संसाधित करना शुरू करता हूं।

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



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

परिनियोजन लेआउट कहाँ प्राप्त करें? ऐसा लगता है कि किसी भी बड़ी कंपनी में एक इन्फ्रास्ट्रक्चर मैनेजमेंट सिस्टम होता है, वहां सब कुछ वर्णित है, यह विश्वसनीय, विश्वसनीय है और यह सब ... वास्तव में नहीं।

कम से कम, दो परियोजनाओं में मेरे अभ्यास से पता चला है कि पहले हार्डकोड करना आसान है, और फिर, तीन साल बाद ... हार्ड-स्किन छोड़ दें।

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

हार्डकोड सचमुच इस तरह हो सकता है:

 public enum Environment { PROD( PROD_UK_PRIMARY, PROD_UK_BACKUP, PROD_US_PRIMARY, PROD_US_BACKUP, PROD_SG_PRIMARY, PROD_SG_BACKUP ) … public Server[] servers() {…} } public enum Server { PROD_UK_PRIMARY(“rflx-ldn-1"), PROD_UK_BACKUP("rflx-ldn-2"), PROD_US_PRIMARY(“rflx-nyc-1"), PROD_US_BACKUP("rflx-nyc-2"), PROD_SG_PRIMARY(“rflx-sng-1"), PROD_SG_BACKUP("rflx-sng-2"), public Service[] services() {…} } 

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



वे प्रत्येक पर्यावरण के लिए सेवाएं चलाते हैं। और सेवाओं () विधि बस अपने सर्वर की फ़ाइल से सभी सेवाओं को grep'a। ऐसा इसलिए किया जाता है क्योंकि बहुत सारे वातावरण नहीं हैं, और सर्वर भी शायद ही कभी जोड़े या हटाए जाते हैं - लेकिन कई सेवाएं हैं, और वे बहुत बार फेरबदल किए जाते हैं। यह स्क्रिप्ट से सेवाओं के वास्तविक लेआउट को लोड करने के लिए समझ में आता है ताकि अक्सर हार्डकोड के लेआउट को भी न बदलें।

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



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

कॉन्फ़िगरेशन मॉडल की प्रासंगिकता बनाए रखने पर सवाल उठता है। आप इसके लिए एक परीक्षण भी लिख सकते हैं।

 public class HardCodedLayoutConsistencyTest { @Theory eachHardCodedEnvironmentHasConfigFiles(Environment env){ … } @Theory eachConfigFileHasHardCodedEnvironment(File configFile){ … } } 

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

निचला रेखा परिनियोजन लेआउट है:

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

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


मान लीजिए कि मैं समझता हूं और सहमत हूं कि यह एक अमान्य नेटवर्क पोर्ट है - लेकिन यह कहां है? बात करने से पहले, मैंने इस तथ्य पर ध्यान दिया कि हमारे पास परियोजना में 1,200 संपत्ति फाइलें हैं, जो 90 से अधिक मॉड्यूलों में बिखरी हुई हैं, जिनमें कुल 24,000 लाइनें हैं। (हालांकि मैं आश्चर्यचकित था, लेकिन अगर आप गिनती करते हैं, तो यह इतनी बड़ी संख्या नहीं है - 4 फाइलों के लिए एक सेवा के लिए।) यह बंदरगाह कहां है?

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

फिर, मैंने सपना देखा और कुछ इस तरह का सपना देखा:

 SELECT environment, server, component, configLocation, propertyName, propertyValue FROM configuration(environment, server, component) WHERE propertyName like “%.port%” and propertyValue is not validNetworkPort() 

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



फिर, इस सबसेट के संबंध में, हम मूल्य के संबंध में कुछ जाँचते हैं:



और फिर, अगर ऐसे गुण थे जिनके मूल्य इच्छा को संतुष्ट नहीं करते हैं, तो यह "शीट" है जिसे हम त्रुटि संदेश में प्राप्त करना चाहते हैं:



एक बार तो मुझे भी लगा कि अगर मैं SQL जैसी लाइक लिख सकता हूं, तो अब मुश्किल नहीं है। लेकिन तब मुझे एहसास हुआ कि आईडीई इसका समर्थन नहीं करेगा और इसे सुझाएगा, इसलिए लोगों को इस स्व-निर्मित "एसक्यूएल" पर आँख बंद करके लिखना होगा, आईडीई प्रॉम्प्ट के बिना, संकलन के बिना, जाँच के बिना - यह बहुत सुविधाजनक नहीं है। इसलिए, मुझे हमारी प्रोग्रामिंग भाषा द्वारा समर्थित समाधानों की तलाश करनी थी। यदि हमारे पास .NET है, तो LINQ मदद करेगा, यह लगभग SQL-जैसा है।

जावा में कोई LINQ नहीं है, जितना संभव हो उतना करीब स्ट्रीम है। इस तरह से इस परीक्षा को धाराओं में देखना चाहिए:

 ValueWithContext[] incorrectPorts = flattenedProperties( environment ) .filter( propertyNameContains( ".port" ) ) .filter( !isInteger( propertyValue ) || !isValidNetworkPort( propertyValue ) ) .toArray(); assertThat( incorrectPorts, emptyArray() ); 

flattenedProperties () इस वातावरण के सभी कॉन्फ़िगरेशन, सभी सर्वरों, सेवाओं के लिए सभी फ़ाइलों को लेती है और उन्हें एक बड़ी तालिका में विस्तारित करती है। यह अनिवार्य रूप से SQL जैसी तालिका है, लेकिन जावा ऑब्जेक्ट के एक सेट के रूप में। और flattenedProperties () स्ट्रिंग्स के इस सेट को एक धारा के रूप में लौटाता है।



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



यदि वे एक खाली सेट नहीं हैं, तो हम एक त्रुटि फेंकते हैं जो इस तरह दिखाई देगी:

भाग 3. रिफैक्टरिंग के लिए समर्थन के रूप में परीक्षण

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

और अब, मेरे सामने कॉन्फ़िगरेशन को फिर से शुरू करने का काम था। एक आवेदन है जो सात साल पहले एक स्मार्ट व्यक्ति द्वारा लिखा गया था। इस एप्लिकेशन का कॉन्फ़िगरेशन कुछ इस तरह दिखता है:



यह एक उदाहरण है, और भी कई हैं। ट्रिपल नेस्टिंग परमिट, और यह पूरे कॉन्फ़िगरेशन में उपयोग किया जाता है:



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

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

और आदमी चला गया। लिखा, आवेदन काम करता है, और उसने बैंक छोड़ दिया। सब कुछ काम करता है, केवल कोई भी पूरी तरह से कॉन्फ़िगरेशन को नहीं समझता है।

यदि हम एक अलग सेवा लेते हैं, तो यह 10 समावेशनों को, तीन गुना गहराई तक, और कुल मिलाकर, अगर सब कुछ विस्तारित हो जाता है, तो 450 मापदंडों को पूरा करता है। वास्तव में, यह विशेष सेवा उनमें से 10-15% का उपयोग करती है, बाकी पैरामीटर अन्य सेवाओं के लिए हैं, क्योंकि फाइलें साझा की जाती हैं, उनका उपयोग कई सेवाओं द्वारा किया जाता है। लेकिन क्या 10-15% इस विशेष सेवा का उपयोग करता है समझने के लिए इतना आसान नहीं है। लेखक ने स्पष्ट रूप से समझा। बहुत होशियार इंसान है, बहुत।

कार्य, क्रमशः, विन्यास को सरल बनाना था, इसकी रीफैक्टरिंग। उसी समय, मैं आवेदन को काम पर रखना चाहता था, क्योंकि इस स्थिति में इस की संभावना कम है। मैं चाहता हूं:

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

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

मैं इस तथ्य की ओर ले जाता हूं कि आप पुराने के साथ नए कॉन्फ़िगरेशन की तुलना नहीं कर सकते। यह समकक्ष हो सकता है, लेकिन एक ही समय में कहीं न कहीं गलत रह सकता है। तार्किक सामग्री की जांच करना आवश्यक है।

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

इसका परीक्षण कैसे करें?

 public class SimpleComponent { … public void configure( final Configuration conf ) { int port = conf.getInt( "Port", -1 ); if( port < 0 ) throw new ConfigurationException(); String ip = conf.getString( "Address", null ); if( ip == null ) throw new ConfigurationException(); … } … } 

मैंने इस समस्या को कैसे हल किया? कुछ सरल घटक है, उदाहरण में इसे अधिकतम तक सरल किया जाता है। (उन लोगों के लिए जो अपाचे कॉमन्स कॉन्फ़िगरेशन में नहीं आए हैं: कॉन्फ़िगरेशन ऑब्जेक्ट प्रॉपर्टीज़ की तरह है, केवल इसमें अभी भी टाइप किए गए तरीके getInt (), getLong (), आदि हैं। हम मान सकते हैं कि ये छोटे स्टेरॉइड्स पर जूप्रोपरेट्स हैं।) मान लीजिए कि एक घटक को दो मापदंडों की आवश्यकता है: उदाहरण के लिए, एक टीसीपी पता और एक टीसीपी पोर्ट। हम उन्हें बाहर खींचते हैं और जांच करते हैं। यहाँ चार सामान्य भाग क्या हैं?



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

 IProperty<Integer> PORT_PROPERTY = intProperty( "Port" ) .withDefaultValue( -1 ) .matchedWith( validNetworkPort() ); IProperty<String> ADDRESS_PROPERTY = stringProperty( "Address" ) .withDefaultValue( null ) .matchedWith( validIPAddress() ); 

इस तरह की एक समग्र वस्तु एक संपत्ति का विवरण है जो अपना नाम, डिफ़ॉल्ट मान जानता है, सत्यापन कर सकता है (यहां मैं फिर से हैमरेस्ट मैचर का उपयोग करता हूं)। और यह ऑब्जेक्ट कुछ इस इंटरफ़ेस की तरह है:

 interface IProperty<T> { /* (name, defaultValue, matcher…) */ /** lookup (or use default), * convert type, * validate value against matcher */ FetchedValue<T> fetch( final Configuration config ) } class FetchedValue<T> { public final String propertyName; public final T propertyValue; … } 

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

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

समस्या को हल करने के लिए मुझे जो दूसरा सरलीकरण चाहिए, वह एक ऐसे घटक को प्रस्तुत करना था, जिसके विन्यास के लिए कई गुणों की आवश्यकता है। घटक विन्यास मॉडल:



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



इस दृश्य की चाल यह है कि मॉडल दहनशील हैं। यदि कोई ऐसा घटक है जो अन्य घटकों का उपयोग करता है, और वे वहां संयुक्त होते हैं, तो उसी तरह इस जटिल घटक का मॉडल दो उप-कंप्यूटरों के कॉल के परिणामों को मिला सकता है।

यही है, स्वयं के घटकों के पदानुक्रम के समानांतर कॉन्फ़िगरेशन मॉडल का एक पदानुक्रम बनाना संभव है। ऊपरी मॉडल पर, कॉल भ्रूण (), जो उन मापदंडों से शीट लौटाएगा जो उन्होंने अपने नामों के साथ कॉन्फ़िगरेशन से खींचा था - बिल्कुल वही जो वास्तविक समय में संबंधित घटक की आवश्यकता होगी। यदि हमने सभी मॉडलों को सही ढंग से लिखा है, तो निश्चित रूप से।

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

इसकी लागत क्या है:

• 12 सेवाएं
• 70 विन्यास योग्य कक्षाएं
• => 70 कॉन्फ़िगरेशनमॉडल (~ 60 तुच्छ हैं);
• 1-2 व्यक्ति सप्ताह।

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

परिणामस्वरूप, जब हम इसे एक साथ रखते हैं, तो हमें निम्नलिखित कोड मिलते हैं:



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

सेवा पर निर्भरता

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

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

 IProperty<IEndpoint> TCP_REQUEST = outcomingTCP( // (+matchers, +default values) “TCP.Request.Address”, “TCP.Request.Port» ); class OutcomingTCPEndpoint implements IEndpoint { //(localInterface, localAddress, multicastGroup, port) @Override boolean matches( IEndpoint other); } 

Endpoint matches(), Endpoint, , .

« »? , : , , - , — . , , / . , , .

, , ---, , Endpoint. ConfigurationModels — , . ? :

 ValueWithContext[] allEndpoints = flattenedConfigurationValues(environment) .filter( valueIsEndpoint() ) .toArray(); ValueWithContext[] unpairedEndpoints = Arrays.stream( allEndpoints ) .filter( e -> !hasMatchedEndpoint(e, allEndpoints) ) .toArray(); assertThat( unpairedEndpoints, emptyArray() ); 

environment' endpoint', , , , . . « » O(n^2), , endpoint' , .

Endpoint , , . , , - .

, , , «» — , . . , , . , .

. , , . , , , c, , .

ConfigurationModel :

• (“ udp-, ”)
• .

, . , , , — . : , . , , , , .

. , ConfigurationModels, . , UDP- , , .

, endpoints , .dot. . — .

. निष्कर्ष:

• , , — .
• , . , .
• , , , .

Heisenbug 2018 Piter , : 6-7 Heisenbug . . 1 — .