API टेस्टिंग मेथड्स, इस आधार पर कि हर एक अकेले क्या पकड़ता है
Smoke
पकड़ता है: डिप्लॉय टूटा हुआ है।
लागत: कुछ मिनट। हमेशा चलाएँ। इतनी जल्दी यह बात और कुछ नहीं बताता।
Functional
पकड़ता है: किसी एक एंडपॉइंट पर गलत व्यवहार, खराब इनपुट के मामले भी।
लागत: मध्यम। वह नींव, जिसे बाकी सब मानकर चलता है।
Integration
पकड़ता है: ऐसे क्रम जो हर कदम पास होने के बावजूद फेल हो जाते हैं।
लागत: ज़्यादा, स्टेट की वजह से। यूज़र को दिखने वाले बग्स के लिए सबसे बड़ा नतीजा।
Regression कोई अलग मेथड नहीं, बल्कि एक लय है: हर बदलाव पर वही चलाना जो आपके पास पहले से मौजूद है। Contract अलग-अलग डिप्लॉय होने वाली सर्विसेज़ के बीच ढाँचे के खिसकाव को पकड़ता है। Load क्षमता की सीमाएँ पकड़ता है। Fuzz खराब फ़ॉर्मैट वाले इनपुट पर होने वाले क्रैश पकड़ता है। सुरक्षा से जुड़ा व्यवहार ऑथराइज़ेशन की गलतियाँ पकड़ता है, और अपनी छवि के मुकाबले कहीं सस्ता है।
जिसे लोग गलत खाने में डाल देते हैं
Regression टेस्टिंग को एक मेथड की तरह गिनाया जाता है और फिर एक गतिविधि की तरह शेड्यूल कर दिया जाता है, आमतौर पर रिलीज़ से पहले। गलती यही है। Regression वही है जो आपके मौजूदा टेस्ट चलने पर करते हैं, और उनकी कीमत लगभग पूरी तरह इस पर टिकी है कि यह कितनी बार होता है। महीने में एक बार चलने वाला regression सुइट वह सुइट है जो समस्याएँ एक महीने देर से ढूँढता है।
सब कुछ किए बिना चुनाव
ज़रूरी एंडपॉइंट्स पर smoke और functional। मौजूद सबसे सस्ता उपयोगी कवरेज।
असली जर्नी पर integration। आपके यूज़र्स को जो बग्स मिलते हैं, वे असल में यहीं रहते हैं।
ऑथराइज़ेशन जाँच। सस्ती, और असली APIs में सबसे ज़्यादा एक्सप्लॉइट की जाने वाली खामी।
Contract, सिर्फ़ तब जब सर्विसेज़ अलग-अलग डिप्लॉय होती हों।
Load और fuzz, तब जब दाँव पर लगी चीज़ इन्हें जायज़ ठहराए। दोनों असली हैं, और दोनों ही पहला निवेश करने के लिए गलत जगह हैं।
ब्लैक बॉक्स बनाम व्हाइट बॉक्स
API के काम में यह फ़र्क़ अब पहले जितना मायने नहीं रखता। पब्लिक इंटरफ़ेस के ज़रिए टेस्ट करना सही डिफ़ॉल्ट है, क्योंकि आपके क्लाइंट यही इस्तेमाल करते हैं। व्हाइट बॉक्स जानकारी यह चुनने में काम आती है कि टेस्ट क्या करना है, यह तय करने में नहीं कि टेस्ट कैसे करना है।
APIs के लिए पिरामिड कहाँ भटकाता है
टेस्ट पिरामिड यूनिट्स और यूज़र इंटरफ़ेस की दुनिया के लिए बनाया गया था, और उसे सीधे API के काम पर लागू करने से एक आम गलती पैदा होती है।
पिरामिड कहता है कि ऊपर धीमे टेस्ट थोड़े ही रखो। APIs के मामले में महँगी लेयर साफ़ नहीं होती: एक API टेस्ट ब्राउज़र टेस्ट से कहीं सस्ता है और यूनिट टेस्ट से कहीं महँगा, और यह वे चीज़ें पकड़ता है जो इनमें से कोई नहीं पकड़ता। जो टीमें API टेस्ट को पिरामिड की पतली चोटी पर बिठाती हैं, उनके पास ऐसे टेस्ट बहुत कम रह जाते हैं, और जो टीमें इन्हें चौड़े आधार पर बिठाती हैं, उनके पास मामूली असर्शन्स से भरा एक धीमा सुइट आ जाता है।
सर्विसेज़ के लिए बेहतर सोच यह है कि पूछा जाए कि कोई सवाल किस लेयर पर जवाब पा भी सकता है। कोई गणना सही है या नहीं, यह यूनिट टेस्ट का काम है। एंडपॉइंट उसे ठीक से लागू करता है या नहीं, यह API टेस्ट का काम है। यूज़र वहाँ तक पहुँचता भी है या नहीं, यह दोनों के ऊपर का काम है। इसके बाद अनुपात किसी डायग्राम से नहीं, आपके प्रोडक्ट से निकलते हैं।
हर मेथड को नीचे से क्या चाहिए
चार चीज़ें तय करती हैं कि कोई API सुइट अपना पहला साल निकाल पाएगा या नहीं: सेशन जो एक्सपायर हो जाते हैं, वैल्यूज़ जो सिर्फ़ रनटाइम पर मौजूद होती हैं, कॉल्स जो एक-दूसरे पर निर्भर होती हैं, और ऐसे रिकॉर्ड जिन्हें कोई साफ़ नहीं करता। TestSprite इन्हें Auto-Authentication, Dynamic Variables, Dependency Chains और Auto-Cleanup के रूप में संभालता है, जिनका ब्यौरा यहाँ है: API टेस्टिंग डॉक्यूमेंटेशन।
टर्मिनल
npm install -g @testsprite/testsprite-cli
testsprite setup
जो लोग लोकल इंस्टॉल नहीं चाहते, उनके लिए डैशबोर्ड यही सब कवर करता है, और पूरा कमांड सरफ़ेस यहाँ मौजूद है: CLI रिपॉज़िटरी।
दो रास्ते हैं, और चुनाव असल में इस बात का है कि पाइपलाइन किसके पास है। डैशबोर्ड से GitHub App जोड़ने के लिए आपकी रिपॉज़िटरी में कोई बदलाव करने की ज़रूरत ही नहीं पड़ती, क्योंकि यह उसी डिप्लॉयमेंट पर प्रतिक्रिया देता है जो आपका बिल्ड पहले से भेजता है। वहीं, एक GitHub Actions स्टेप जोड़ने से यह जाँच रिपो के भीतर आ जाती है, जहाँ बाकी बिल्ड की तरह इसका भी रिव्यू होता है।
TestSprite कौन-से मेथड कवर करता है
Functional और integration, साथ में security का व्यवहार वाला हिस्सा, और regression एक गतिविधि के बजाय एक लय के रूप में। जो प्लान बनते हैं वे functional, schema, authorization, error-handling और boundary श्रेणियों तक फैले होते हैं, और सादी भाषा में उन्हें निखारा जाता है।
Auto-Authentication पूरे रन के दौरान सेशन ज़िंदा रखता है, Dynamic Variables कॉल्स के बीच वैल्यूज़ पहुँचाता है, Dependency Chains इससे एक्ज़ीक्यूशन का क्रम निकालता है कि हर केस को क्या चाहिए और वह क्या पैदा करता है, और Auto-Cleanup ठीक वही हटाता है जो उस रन ने बनाया था। यही वह चीज़ है जो regression को सचमुच लगातार चलने देती है, न कि रिलीज़ से पहले शेड्यूल की गई कोई गतिविधि बनाकर रख देती है — और यही अकेली सबसे बड़ी बात तय करती है कि कोई भी मेथड कीमत लौटाता है या नहीं।
Contract, load और fuzzing अलग औज़ार बने रहते हैं। फ़ायदा यह है कि सबसे ज़्यादा नतीजे देने वाले तीन मेथड टेस्ट लिखने के समय के लिए फ़ीचर के काम से होड़ करना बंद कर देते हैं, इसलिए कवरेज सिर्फ़ योजना में नहीं, हक़ीक़त में होता है।
सबसे ज़्यादा बग कौन-सा मेथड ढूँढता है?
ज़्यादातर प्रोडक्ट्स में integration, क्योंकि यूज़र को दिखने वाली गड़बड़ियाँ आमतौर पर किसी एक कॉल के भीतर नहीं, कॉल्स के बीच में उभरती हैं।
क्या smoke टेस्टिंग के लिए अलग सुइट रखना सही है?
हाँ। हर डिप्लॉय पर चलने वाली दो मिनट की जाँच का काम बीस मिनट के सुइट से अलग है, और दोनों को एक कर देने का मतलब है कि कोई भी सही समय पर नहीं चलेगा।
क्या हमें fuzz टेस्टिंग चाहिए?
अगर आपकी सर्विस तक खराब फ़ॉर्मैट वाला इनपुट पहुँचने के असली नतीजे होते हैं, तो हाँ। ज़्यादातर इंटरनल APIs के लिए इसकी प्राथमिकता ऑथराइज़ेशन जाँच और integration कवरेज से नीचे है।
exploratory API टेस्टिंग का क्या?
यह सचमुच कीमती है और इसे ऑटोमेट नहीं किया जा सकता। जब कोई API नया हो या उसमें बड़ा बदलाव हुआ हो, तब यह करें, और फिर जो मिला उसे टेस्ट में उतार दें।
ये टेस्ट पिरामिड पर कैसे बैठते हैं?
ढीले-ढाले तरीके से। पिरामिड यूनिट और UI के लिए बनाया गया था। APIs के लिए काम का पैमाना यह है कि हर जाँच अकेले क्या पकड़ती है, न कि वह किस लेयर की है।
चुनाव इस आधार पर करें कि हर मेथड अकेले क्या पकड़ता है।
API टेस्टिंग मेथड्स को रटने के बजाय लागत बनाम अलग नतीजे के हिसाब से क्रम में रखना बेहतर है। पहले smoke और functional, असली बग्स के लिए integration, ऑथराइज़ेशन जाँच इसलिए क्योंकि वे सस्ती हैं, और सबसे आख़िर में load।