सभी को नमस्कार, आप यहाँ आएँ TestMace! शायद बहुत से लोग हमारे बारे में जानते होंगे हमारे पिछला सामग्री. उन लोगों के लिए जो अभी शामिल हुए हैं: हम TestMace API के साथ काम करने के लिए एक IDE विकसित कर रहे हैं। TestMace की प्रतिस्पर्धी उत्पादों से तुलना करते समय सबसे अक्सर पूछा जाने वाला प्रश्न है "आप पोस्टमैन से कैसे भिन्न हैं?" हमने निर्णय लिया कि अब इस प्रश्न का विस्तृत उत्तर देने का समय आ गया है। नीचे हमने अपने फायदे बताए हैं पोस्टमैन.

नोड्स में विभाजित करना

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

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

मानव-पठनीय परियोजना प्रारूप

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

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

यह उपयोगकर्ता को क्या देता है? यह आपको परिचित दृष्टिकोणों का उपयोग करके टीम के कार्य प्रवाह को बहुत लचीले ढंग से बदलने की अनुमति देता है। उदाहरण के लिए, डेवलपर्स किसी प्रोजेक्ट को बैकएंड के समान रिपॉजिटरी में संग्रहीत कर सकते हैं। शाखाओं में, कोड आधार को बदलने के अलावा, डेवलपर मौजूदा क्वेरी स्क्रिप्ट और परीक्षणों को सही कर सकता है। रिपॉजिटरी में परिवर्तन करने के बाद (git, svn, mercurial - जो भी आपको सबसे अच्छा लगे), CI (आपका पसंदीदा, किसी के द्वारा थोपा हुआ नहीं) हमारी कंसोल उपयोगिता लॉन्च करता है testmace-cli, और निष्पादन के बाद प्राप्त रिपोर्ट (उदाहरण के लिए, जूनिट प्रारूप में, जो टेस्टमेस-सीएलआई में भी समर्थित है) उपयुक्त सिस्टम को भेजी जाती है। और उपर्युक्त सुरक्षा समस्या अब कोई समस्या नहीं है।

जैसा कि आप देख सकते हैं, TestMace अपना पारिस्थितिकी तंत्र और प्रतिमान थोपता नहीं है। इसके बजाय, यह स्थापित प्रक्रियाओं में आसानी से फिट हो जाता है।

गतिशील चर

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

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

var jsonData = JSON.parse(responseBody);
postman.setEnvironmentVariable("data", jsonData.data);

लेकिन हमारी राय में, ऐसे सरल और अक्सर उपयोग किए जाने वाले परिदृश्य के लिए स्क्रिप्ट लिखना बेमानी लगता है। इसलिए, TestMace में ग्राफिकल इंटरफ़ेस का उपयोग करके एक वेरिएबल के उत्तर का एक टुकड़ा निर्दिष्ट करना संभव है। देखो यह कितना सरल है:

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

var jsonData = JSON.parse(responseBody);
postman.setEnvironmentVariable("data", CryptoJS.MD5(jsonData.data));

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

const data = tm.currentNode.prev.response.body.data;
tm.currentNode.parent.setDynamicVar('data', crypto.MD5(data));

जैसा कि आप देख सकते हैं, नोड्स की संरचना ने यहां भी अच्छा काम किया। और ऊपर वर्णित ऐसे सरल मामले के लिए, आप बस अभिव्यक्ति निर्दिष्ट कर सकते हैं ${crypto.MD5($response.data)} GUI के माध्यम से बनाया गया वेरिएबल!

जीयूआई के माध्यम से परीक्षण बनाना

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

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

हालाँकि, ग्राफ़िकल संपादक में परीक्षण बनाने से संभावना समाप्त नहीं होती है कोड में परीक्षण लिखना. स्क्रिप्ट नोड की तरह सभी समान लाइब्रेरी यहां मौजूद हैं, और चाय लेखन परीक्षण के लिए.

एक लिंक के माध्यम से मौजूदा स्क्रिप्ट को चलाने की क्षमता (लिंक नोड)

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

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

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

अन्य मतभेद

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

वे सुविधाएँ जो पहले से ही उपलब्ध हैं

हम अगली रिलीज़ पर गोपनीयता का पर्दा उठाने के प्रलोभन का विरोध नहीं कर सके, खासकर जब कार्यक्षमता बहुत स्वादिष्ट है और पहले से ही प्री-रिलीज़ पॉलिशिंग के दौर से गुजर रही है। तो चलिए मिलते हैं.

कार्य

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

{{$randomEmail}}

हालाँकि, चूंकि ये वेरिएबल हैं (यद्यपि गतिशील हैं), इन्हें फ़ंक्शन के रूप में उपयोग नहीं किया जा सकता है: वे पैरामीटर योग्य नहीं हैं, इसलिए एक स्ट्रिंग से हैश लेना संभव नहीं होगा।

हम TestMace में "ईमानदार" फ़ंक्शन जोड़ने की योजना बना रहे हैं। ${} के ठीक अंदर न केवल एक वेरिएबल तक पहुंचना संभव होगा, बल्कि एक फ़ंक्शन को कॉल करना भी संभव होगा। वे। यदि आपको कुख्यात नकली ईमेल उत्पन्न करने की आवश्यकता है, तो हम बस लिख देंगे

${faker.internet.email()}

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

यदि हम किसी स्ट्रिंग के हैश की गणना करना चाहें तो क्या होगा? आसानी से!

${crypto.MD5($dynamicVar.data)}

आप देखेंगे कि आप वेरिएबल को पैरामीटर के रूप में भी पास कर सकते हैं! इस बिंदु पर, एक जिज्ञासु पाठक को संदेह हो सकता है कि कुछ गड़बड़ है...

अभिव्यक्तियों में जावास्क्रिप्ट का उपयोग करना

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

${1 + '' + crypto.MD5('asdf')}

और यह सब बिना स्क्रिप्ट के, सीधे इनपुट फ़ील्ड में!

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

उन्नत स्वतः पूर्णता

वर्तमान में TestMace में एक मानक स्वत: पूर्णता है जो इस तरह दिखती है:

यहां ऑटो-कम्प्लीट लाइन के अलावा यह भी दर्शाया गया है कि यह लाइन किससे संबंधित है। यह तंत्र केवल कोष्ठक ${} से घिरे भावों में काम करता है।

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

सबसे पहले, स्वत: पूर्णता अभिव्यक्तियों (जहां संभव हो) में भी काम करती है। यह है जो ऐसा लग रहा है:

और दूसरी बात, स्वतः पूर्णता अब स्क्रिप्ट में उपलब्ध है। देखिये यह कैसे काम करता है!

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

निष्कर्ष

अक्टूबर में हमारे उत्पाद विकास को शुरू हुए एक साल पूरा हो गया। इस दौरान हम बहुत सी चीजें करने में कामयाब रहे और कुछ मामलों में अपने प्रतिस्पर्धियों से आगे निकल गये। लेकिन जैसा भी हो, हमारा लक्ष्य एपीआई के साथ काम करने के लिए वास्तव में सुविधाजनक उपकरण बनाना है। हमें अभी भी बहुत काम करना है, यहां आने वाले वर्ष के लिए हमारी परियोजना के विकास की एक अनुमानित योजना है: https://testmace.com/roadmap.

आपकी प्रतिक्रिया हमें सुविधाओं की प्रचुरता को बेहतर ढंग से नेविगेट करने की अनुमति देगी, और आपका समर्थन हमें ताकत और आत्मविश्वास देता है कि हम सही काम कर रहे हैं। ऐसा होता है कि आज हमारे प्रोजेक्ट के लिए एक महत्वपूर्ण दिन है - जिस दिन TestMace प्रकाशित हुआ था ProductHunt. कृपया हमारे प्रोजेक्ट का समर्थन करें, यह हमारे लिए बहुत महत्वपूर्ण है। इसके अलावा, आज हमारे PH पेज पर एक आकर्षक ऑफर है, और यह सीमित है

स्रोत: www.habr.com