सभी को नमस्कार!
मुझे यह लेख लिखने के लिए मेरे छात्रों और शिष्यों ने प्रेरित किया। मैं अक्सर उन्हें सलाह देता हूं कि जैसे ही वे जावास्क्रिप्ट पर परीक्षण स्वचालन प्रक्रिया के साथ सहज हो जाएं, टाइपस्क्रिप्ट सीख लें। आइए देखें कि REST API परीक्षण के संदर्भ में आपके परीक्षण स्वचालन ढांचे में टाइपस्क्रिप्ट का उपयोग करने की विशेषताएं क्या हैं…
आप किसी परीक्षण प्रोजेक्ट का पूरा कोड यहां पा सकते हैं।
आइए ज्यादा गहराई में न जाएं कि टाइपस्क्रिप्ट क्या है और यह जावास्क्रिप्ट से कैसे अलग है और महत्वपूर्ण बात बताते हैं -
टाइपस्क्रिप्ट को Node.js पैकेज के रूप में प्रस्तुत किया गया है, इसलिए मैं इसे कुछ शानदार सुविधाओं के साथ जावास्क्रिप्ट के रूप में देखता हूं।
भाषा के बारे में और यह क्या पेशकश करती है, इसके बारे में अधिक जानने के लिए कृपया आधिकारिक वेबसाइट पर जाएँ, जबकि हम परीक्षण स्वचालन के संदर्भ में इसकी विशेषताओं के बारे में बात करने जा रहे हैं...
आइए टाइपस्क्रिप्ट पर परीक्षण स्वचालन परियोजना निर्माण प्रक्रिया से गुजरें:
एक Node.js प्रोजेक्ट बनाएं.
npm init -y
टाइपस्क्रिप्ट पैकेज स्थापित करें।
npm i typescript
प्रोजेक्ट के लिए एक डिफ़ॉल्ट टाइपस्क्रिप्ट कॉन्फ़िगरेशन जेनरेट करें - tsconfig.json
।
npx tsc --init
उपरोक्त आदेश एक डिफ़ॉल्ट कॉन्फ़िगरेशन फ़ाइल उत्पन्न करेगा, लेकिन मैं इसे कुछ इस तरह छोटा करने की सलाह देता हूं:
{ "compilerOptions": { "baseUrl": "./", "module": "esnext", "target": "esnext", "sourceMap": false, "moduleResolution": "node", "allowJs": true, "skipLibCheck": true, "resolveJsonModule": true, "allowSyntheticDefaultImports": true, "paths": { "*": ["./*"] } } }
इस कॉन्फ़िगरेशन में आवश्यक न्यूनतम शामिल है:
आप आधिकारिक दस्तावेज़ीकरण का उपयोग करके अपनी कॉन्फ़िगरेशन का विस्तार कर सकते हैं।
आप Node.js पारिस्थितिकी तंत्र द्वारा पेश किए गए किसी भी उपकरण का उपयोग कर सकते हैं, लेकिन मेरे अनुभव में - टाइपस्क्रिप्ट के साथ काम करने वाले अधिकांश इंजीनियर कुछ अच्छे कारणों से जेस्ट चुनते हैं:
पहले, मुझे परियोजना के मूल को स्थापित करने के लिए मोचा + चाय का उपयोग करने में मज़ा आया था, लेकिन अब मैं जेस्ट पर भी कायम हूं, क्योंकि इसमें टेस्ट रनर और अभिकथन लाइब्रेरी दोनों शामिल हैं।
एक्सिओस सबसे लोकप्रिय HTTP क्लाइंट प्रतीत होता है, इसलिए मेरा सुझाव है कि यह आपकी पसंद भी है।
यह नहीं कह सकता कि आपको अपने सेटअप के लिए इसका उपयोग करने के लिए मजबूर किया जाता है, लेकिन मैं कह रहा हूं कि जब आप परियोजनाओं को देखते हैं तो यह सामान्य बात है।
अब, बस इन पैकेजों को निर्भरता के रूप में स्थापित करें:
npm i jest axios
कुछ पैकेजों (जैसे एक्सियोस ) में टाइपस्क्रिप्ट प्रकार होते हैं, लेकिन जेस्ट और मोचा में नहीं होते हैं। इसके अलावा, जेस्ट को ठीक से काम करने के लिए @types/jest के साथ एक ts-jest पैकेज की आवश्यकता होती है - पहला टाइपस्क्रिप्ट सुविधाओं को सक्षम करता है और दूसरा आपको IntelliSense का उपयोग करने देता है।
इसलिए ध्यान रखें - यदि आपके पास कुछ पैकेजों का उपयोग करने का प्रयास करते समय स्वत: पूर्ण सुविधा नहीं है - तो आप संभवतः प्रकार की घोषणाओं से चूक रहे हैं।
आइए टाइपस्क्रिप्ट -संबंधित एक्सटेंशन (पैकेज) भी इंस्टॉल करें:
npm i ts-jest @types/jest
जेस्ट को ts-jest कॉन्फिग प्रीसेट की आवश्यकता होती है, इसलिए आपको इसे अपनी कॉन्फिग (या package.json ) फ़ाइल में घोषित करना होगा:
{ "jest": { "preset": "ts-jest" } }
यदि आप किसी प्रोजेक्ट के भीतर निरपेक्ष पथ का उपयोग करने की योजना बना रहे हैं, तो आपको अपनी कॉन्फ़िगरेशन को भी समायोजित करने की आवश्यकता होगी:
{ "jest": { "preset": "ts-jest", "moduleDirectories": [ "node_modules", "<rootDir>" ] } }
यह कॉन्फ़िगरेशन आपको एक साधारण कमांड के साथ परीक्षण चलाने की अनुमति देता है... jest
तो, अपनी परीक्षण स्क्रिप्ट को package.json में इस प्रकार कॉन्फ़िगर करें:
{ "scripts": { "test": "jest" } }
और फिर किसी भी समय npm test
या npm run test
कमांड के साथ अपने परीक्षण चलाएं।
यदि आप विज़ुअल स्टूडियो कोड उपयोगकर्ता हैं तो मैं आपको जेस्ट रनर एक्सटेंशन इंस्टॉल करने की भी सलाह देता हूं - यह आपको केवल एक क्लिक के साथ वांछित परीक्षण/सूट चलाने / डीबग करने की अनुमति देता है। वेबस्टॉर्म में, यह एक अंतर्निहित सुविधा है।
टाइपस्क्रिप्ट द्वारा REST API परीक्षण में पेश की जाने वाली मुख्य विशेषता है...
आप घोषित कर सकते हैं कि आपका अनुरोध और प्रतिक्रिया निकाय कैसा दिखना चाहिए, यानी,
आइए एक पेसिस सर्वर को एक उदाहरण के रूप में लें - हम /auth
एंडपॉइंट के लिए इसके अनुरोध बॉडी पेलोड को एक प्रकार के रूप में लिख सकते हैं:
export type AuthRequestBody = { login: string password: string }
और प्रतिक्रिया निकाय के लिए भी यही बात है - सर्वर को हमारे अनुरोध पर क्या भेजना चाहिए:
export type AuthResponseBody = { token?: string message?: string }
चूंकि सफलता/असफलता परिदृश्यों के लिए एक अलग पेलोड होगा - आप " ?" के माध्यम से कुंजियों को "वैकल्पिक" के रूप में चिह्नित कर सकते हैं। चरित्र।
एक बार यह हो जाए - आप अपने परीक्षणों में अनुरोध और सत्यापन लिखने के लिए इन प्रकारों का उपयोग कर सकते हैं...
Axios में, आप अनुरोध कॉन्फ़िगरेशन के माध्यम से बता सकते हैं कि आप कौन सा निकाय भेज रहे हैं:
const payload: AxiosRequestConfig<AuthRequestBody> = { method: 'post', url: '/auth', data: { login: process.env.USERNAME, password: process.env.PASSWORD, }, }
AxiosRequestConfig<AuthRequestBody>
में AuthRequestBody
मतलब बिल्कुल यही है ☝️
इसका मतलब है कि आपको उस पेलोड का उपयोग करने के लिए मजबूर किया जाएगा जो data
ऑब्जेक्ट में दिए गए प्रकार AuthRequestBody
से मेल खाता है। यदि आप कुछ आवश्यक फ़ील्ड सेट करना भूल जाते हैं या कुछ अत्यधिक फ़ील्ड सेट करना भूल जाते हैं - तो आपको एक त्रुटि दिखाई देगी।
यही बात प्रतिक्रिया के बारे में भी की जा सकती है:
const response: AxiosResponse<AuthResponseBody> = await client.request(payload)
यह response.data
ऑब्जेक्ट में स्वत: पूर्ण जोड़ देगा, जिससे आप response.data.token
या response.data.message
फ़ील्ड तक पहुंचने में सक्षम होंगे।
उपरोक्त सरल सामग्री के अलावा, आपके कस्टम प्रकारों से JSON स्कीमा उत्पन्न करना भी संभव है। यह आपको प्रतिक्रिया निकाय में प्रत्येक कुंजी की जांच करने की अनुमति नहीं देता है, यह देखने के लिए कि क्या यह स्कीमा से मेल खाता है, बल्कि पूरे पेलोड की जांच करता है ।
तो विचार यह है:
बहुत बढ़िया चीज़, लेकिन ध्यान रखें कि इन परिवर्तनों के बाद आपके परीक्षण ख़राब हो सकते हैं - ऐसा तब होता है जब कुछ अतिरिक्त फ़ील्ड दिखाई देते हैं, इसलिए आपको नियमित रूप से स्कीमा को अपडेट करने की आवश्यकता होगी।
टाइपस्क्रिप्ट सेटअप मुश्किल हो सकता है, खासकर यदि यह आपका पहली बार है, लेकिन यह इसके लायक है!
यदि आप अपने इनपुट और आउटपुट डेटा को प्रकारों के साथ कवर करते हैं - तो इन ऑब्जेक्ट्स को पार्स करते समय कोई भी तरीका नहीं है कि आप टाइपो या कोई अन्य सिंटैक्स त्रुटि करेंगे। यह आपको साधारण गलतियों से बचाता है और आपको आपके अनुरोधों की संरचना को सीधे आपके कोड में देखने की सुविधा देता है, इसलिए आपको कोई HTTP संग्रह ( पोस्टमैन की तरह) खोलने की ज़रूरत नहीं है और आपको यह देखने के लिए अनुरोध की तलाश नहीं करनी है कि यह किस निकाय से अनुरोध/प्रतिक्रिया करता है। साथ।
मुझे अपने अनुभव के बारे में बताएं और आप इसके बारे में क्या सोचते हैं।