4 मिनट में यूनिट परीक्षणों या 17,000 परीक्षणों का इष्टतम समानांतर

आज हम उस उपयोगिता के बारे में बात करेंगे जिसे हमने विकसित किया है जो PHPUnit और TeamCity का उपयोग करके PHP कोड के परीक्षण का अनुकूलन करता है। उसी समय, आपको यह समझने की आवश्यकता है कि हमारी परियोजना न केवल एक वेबसाइट है, बल्कि मोबाइल एप्लिकेशन, एक वैप साइट, एक फेसबुक एप्लीकेशन और भी बहुत कुछ है, और विकास केवल PHP में नहीं है, बल्कि C, C ++, HTML5 और में भी है आदि

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

इसकी आवश्यकता क्यों है?

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

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

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

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

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

निष्कर्ष : हमें एक आसान-प्रबंधन प्रणाली की आवश्यकता है जो स्वचालित रूप से और समान रूप से धाराओं के पार परीक्षण वितरित करेगी और परीक्षणों के साथ स्वतंत्र रूप से कोड कवरेज को नियंत्रित करेगी।

खोज

चूंकि PHPUnit एक बहुत ही सामान्य प्रणाली है, हमने सोचा कि शायद किसी ने पहले ही कुछ ऐसा ही किया था, और खोज करना शुरू कर दिया।

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

अधिकांश विकल्प दो योजनाओं में से एक के अनुसार बनाए गए थे:

• हम सभी आवश्यक फाइलों की तलाश करते हैं और उन्हें धाराओं के बीच समान रूप से विभाजित करते हैं;
• हम धागे की एक निश्चित संख्या शुरू करते हैं जो क्रमिक रूप से परीक्षणों की सामान्य कतार को संसाधित करते हैं और उन्हें PHPUnit को "फ़ीड" करते हैं।

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

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

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

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

रचनात्मकता का प्रवाह

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

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

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

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

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

निर्णय

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

हमारे मल्टीथ्रेड लॉन्चर (या, जैसा कि हम प्यार से इसे कहते हैं, "लॉन्चर") में तीन अलग-अलग वर्ग होते हैं:

• परीक्षण निष्पादन समय पर आंकड़े एकत्र करने और सहेजने के लिए एक वर्ग;
• इन आँकड़ों को प्राप्त करने और परीक्षणों के वितरण के लिए एक वर्ग;
• PHPUnit कॉन्फ़िगरेशन फ़ाइलों को बनाने और इसकी प्रक्रिया शुरू करने के लिए एक वर्ग।

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

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



यह एक बजाय संसाधन-गहन कार्य की तरह लग सकता है, लेकिन हमने "पत्राचार" वर्ग => फ़ाइल "पत्राचार के लिए एक सरल प्रणाली लिखी, और कड़ी मेहनत कलेक्टर द्वारा ही की जाती है यदि नई कक्षाएं दिखाई देती हैं, और प्रत्येक प्रारंभ में उनकी संख्या इतनी बड़ी नहीं होती है।

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

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

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

हमारे TestListener'ah की बात करें ( यह मानक PHPUnit इंटरफ़ेस है जो प्रदर्शन किए गए परीक्षणों के बारे में जानकारी प्रदर्शित करने के लिए उपयोग किया जाता है )। प्रारंभ में, लांचर ने डिफ़ॉल्ट रूप से PHPUnit के रूप में उसी रूप में जानकारी प्रदर्शित की। लेकिन अधिक सुविधा के लिए, हमने अपना स्वयं का श्रोता लिखा, जिसने हमें जानकारी को अधिक कॉम्पैक्ट और पठनीय बनाने की अनुमति दी और साथ ही STDOUT और STDERR को इंटरसेप्ट करने जैसी नई सुविधाएँ भी जोड़ीं।

इसके अलावा, हमारे पास TeamCity में उस रूप में जानकारी प्रदर्शित करने के लिए एक TestListener है जिसमें यह अपेक्षा करता है ( इतना डरावना है कि परिणामस्वरूप एक लॉन्च पर पाठ रिपोर्ट का वजन पांच मेगाबाइट तक पहुंच जाता है )।

परिणाम

अब कुछ संख्या।
हम 8 थ्रेड्स में 17 हजार से अधिक परीक्षण करते हैं ( प्लस "धीमी" परीक्षणों के लिए तीन अतिरिक्त वाले, जो एक सामान्य स्थिति में एक मिनट में सभी एक साथ गुजरते हैं )।
सर्वोत्तम स्थिति में ( परीक्षण सर्वर के एक मानक भार के साथ), समान रूप से वितरित होने पर 3.5-4 मिनट बनाम 40-50 मिनट एक धागे में स्टार्टर पास की मदद से और 8-15 मिनट में परीक्षण।
भारी लोड वाले सर्वर के साथ, लांचर जल्दी से स्थिति के अनुकूल हो जाता है और 8-10 मिनट में काम करता है। परीक्षणों को समान रूप से वितरित करते समय, उन्होंने कम से कम 20-25 मिनट तक काम किया ... और हमने कभी भी एक धागे में परीक्षणों को पूरा करने के लिए इंतजार नहीं किया।



नतीजतन, हमें एक ऐसी प्रणाली मिली जो स्वतंत्र रूप से TeamCity से प्राप्त आँकड़ों की बदौलत सर्वर पर लोड में बदलावों को स्वीकार करती है, स्वचालित रूप से प्रवाह द्वारा परीक्षण वितरित करती है, और आसानी से प्रबंधित और कॉन्फ़िगर की जाती है।

हमें ऐसे त्वरित परीक्षण निष्पादन क्या दिया?

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

आगे क्या है?

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

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

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

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

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

इल्या कुडिनोव, क्यूए इंजीनियर।