API फंक्शनल टेस्टिंग के चार स्तर
1. स्टेटस
क्या उसने 200 लौटाया।
आउटेज पकड़ता है। जहाँ कोई रिकॉर्ड होना चाहिए वहाँ खाली परिणाम मिलने पर भी खुशी-खुशी पास हो जाता है।
2. शेप
क्या अपेक्षित फ़ील्ड अपेक्षित टाइप के साथ मौजूद हैं।
स्कीमा ड्रिफ़्ट पकड़ता है। वैल्यू सही हैं या नहीं, इस बारे में कुछ नहीं बताता।
3. वैल्यू
क्या टोटल सचमुच योग है, क्या स्टेटस वही है जो इस एक्शन से बनना चाहिए।
जहाँ से असली डिफ़ेक्ट पकड़ में आने लगते हैं।
चौथा है रिलेशनशिप: ऑर्डर बनाने के बाद, कस्टमर को फ़ेच करने पर क्या वह दिखता है। ज़्यादातर दिलचस्प बग एक कॉल के भीतर नहीं, दो कॉल के बीच रहते हैं, और चौथा स्तर ही अकेला ऐसा है जो वहाँ देखता है।
सुइट दूसरे स्तर पर क्यों रुक जाते हैं
क्योंकि तीसरे और चौथे स्तर को यह पता होना चाहिए कि "सही" का मतलब क्या है, यानी किसी न किसी को तय करना पड़ेगा। स्टेटस और शेप स्पेसिफ़िकेशन से यांत्रिक रूप से निकाले जा सकते हैं। वैल्यू और रिलेशनशिप के लिए प्रोडक्ट के बारे में एक फ़ैसला चाहिए।
यह सचमुच ज़्यादा मुश्किल है, और यही इसकी पूरी कीमत भी है। जो सुइट कभी कोई प्रोडक्ट नियम व्यक्त ही नहीं करता, वह बस विस्तृत तरीके से यह जाँच रहा है कि सर्विस ऑनलाइन है।
वह नेगेटिव केस जिसे लोग छोड़ देते हैं
हर एंडपॉइंट के लिए पूछें कि क्या-क्या रिजेक्ट होना चाहिए, फिर असर्ट करें कि वह सचमुच रिजेक्ट होता है। रेंज से बाहर की वैल्यू, गायब ज़रूरी फ़ील्ड, किसी और का आइडेंटिफ़ायर। ऐसी सर्विसेज़ इतनी आम हैं जो बॉडी में एरर ऑब्जेक्ट के साथ 200 लौटाती हैं कि इस पैटर्न से अनजान सुइट हमेशा हरा ही रिपोर्ट करता रहेगा।
सुइट को नीचे की परत में क्या चाहिए
चार चीज़ें तय करती हैं कि कोई API सुइट अपना पहला साल निकाल पाएगा या नहीं: सेशन जो एक्सपायर हो जाते हैं, वैल्यू जो सिर्फ़ रनटाइम पर मौजूद होती हैं, कॉल जो एक-दूसरे पर निर्भर होते हैं, और रिकॉर्ड जिन्हें कोई साफ़ नहीं करता। TestSprite इन्हें Auto-Authentication, Dynamic Variables, Dependency Chains और Auto-Cleanup के रूप में संभालता है; इनका विवरण यहाँ है: API टेस्टिंग डॉक्युमेंटेशन।
इन्हें सही कर लेने पर ही आप अपना ध्यान इन्फ़्रास्ट्रक्चर के बजाय तीसरे और चौथे स्तर पर लगा पाते हैं।
कवरेज को उथले हिस्से से आगे ले जाना
जेनरेट किए गए प्लान किसी स्पेसिफ़िकेशन या एक डिस्कवरी पास से शुरू होते हैं और उनमें फंक्शनल, स्कीमा, ऑथराइज़ेशन, एरर-हैंडलिंग और बाउंड्री कैटेगरी शामिल रहती हैं, इसलिए नेगेटिव केस डिफ़ॉल्ट रूप से मौजूद होते हैं — इस पर निर्भर नहीं रहते कि स्प्रिंट के आख़िर में किसी को वे याद आएँ।
टर्मिनल
npm install -g @testsprite/testsprite-cli
testsprite setup
अगर आप लोकली कुछ भी इंस्टॉल नहीं करना चाहते, तो यही सेटअप TestSprite डैशबोर्ड में भी उपलब्ध है। बाक़ी पूरा CLI सरफ़ेस यहाँ है: CLI रिपॉज़िटरी।
तय करना कि किन एंडपॉइंट को चौथा स्तर मिले
रिलेशनशिप असर्शन सबसे कीमती भी हैं और सबसे महँगे भी, इसलिए ये हर जगह नहीं होने चाहिए। जो फ़िल्टर काम करता है वह यह है: पूछिए कि एक ग़लत जवाब की कीमत क्या होगी।
जो कुछ भी पैसे की आवाजाही करता है, परमिशन बदलता है, या किसी और के फ़ैसले का आधार बनता है, उसे चौथा स्तर मिलना चाहिए। ऐसा ऑर्डर जो मौजूद है पर किसी कस्टमर से जुड़ा नहीं, ऐसा परमिशन ग्रांट जो सिर्फ़ एक तरफ़ सफल हुआ, ऐसी रिपोर्ट जो भीतर से सुसंगत है पर अंतर्निहित रिकॉर्ड से मेल नहीं खाती। यही वे विफलताएँ हैं जो महँगी भी होती हैं और चुपचाप भी।
रीड-ओनली रिपोर्टिंग एंडपॉइंट, हेल्थ चेक और ऐसा कुछ भी जिसका आउटपुट कोई इंसान तुरंत देख लेता है — इन्हें इसकी ज़रूरत नहीं। इस बारे में सोच-समझकर चुनाव करना ही सुइट को इतना तेज़ रखता है कि लोग उसे चलाएँ।
हर बदलाव पर इसे चलाएँ
दो रास्ते हैं, और चुनाव असल में इस बात का है कि पाइपलाइन किसके ज़िम्मे है। डैशबोर्ड से GitHub App जोड़ने पर आपकी रिपॉज़िटरी में कोई बदलाव करने की ज़रूरत ही नहीं पड़ती, क्योंकि यह उसी डिप्लॉयमेंट पर प्रतिक्रिया देता है जो आपका बिल्ड पहले से भेजता है। एक GitHub Actions स्टेप जोड़ने से यह जाँच रिपो के भीतर आ जाती है, जहाँ बाक़ी बिल्ड की तरह इसका भी रिव्यू होता है।
TestSprite आपको दूसरे स्तर से आगे कैसे ले जाता है
जेनरेट किए गए प्लान में नेगेटिव केस डिफ़ॉल्ट रूप से शामिल रहते हैं — फंक्शनल, स्कीमा, ऑथराइज़ेशन, एरर-हैंडलिंग और बाउंड्री कैटेगरी में — और यही वह जगह है जहाँ हाथ से लिखे ज़्यादातर सुइट का दम टूट जाता है। आप उन्हें सादी भाषा में निखारते हैं, और उसी निखार के रास्ते आपका प्रोडक्ट ज्ञान सुइट में दाखिल होता है।
वैल्यू और रिलेशनशिप वाले स्तर ही आपके ध्यान के लायक हैं, और यही वे स्तर हैं जिनके लिए ऐसा कोई चाहिए जो प्रोडक्ट को जानता हो। Auto-Authentication पूरे रन के दौरान सेशन ज़िंदा रखता है, Dynamic Variables कॉल के बीच वैल्यू ले जाते हैं, Dependency Chains हर केस की ज़रूरत और उसके नतीजे से एक्ज़ीक्यूशन का क्रम निकालते हैं, और Auto-Cleanup ठीक वही हटाता है जो रन ने बनाया था। इससे आपका समय इन्फ़्रास्ट्रक्चर पर नहीं, इस पर लगता है कि "सही" का मतलब क्या है।
नतीजा एक ऐसा सुइट है जो बॉडी पर और कॉल के आपसी रिश्तों पर असर्शन करता है और हर बदलाव पर चलता है — न कि एक हरी पाइपलाइन जो बस इतना साबित करती है कि सर्विस ऑनलाइन है।
क्या स्टेटस कोड असर्शन बेकार है?
नहीं, वह बस न्यूनतम ज़मीन है। उसे रखें और हर अहम एंडपॉइंट के लिए कम से कम एक वैल्यू-स्तर का असर्शन जोड़ें।
हम कैसे तय करें कि "सही" का मतलब क्या है?
पूछें कि प्रोडक्ट क्या वादा करता है, यह नहीं कि कोड क्या करता है। अगर किसी एंडपॉइंट के लिए कोई जवाब न दे पाए, तो वह अस्पष्टता ख़ुद सामने लाने लायक है।
क्या हर एंडपॉइंट को चारों स्तर मिलने चाहिए?
नहीं। तीसरे और चौथे स्तर उन्हीं एंडपॉइंट के लिए रखें जहाँ ग़लत वैल्यू के नतीजे भुगतने पड़ते हैं। रिपोर्टिंग एंडपॉइंट और हेल्थ चेक को इनकी ज़रूरत नहीं।
जेनरेट किए गए असर्शन का क्या?
पहले और दूसरे स्तर के लिए काम के हैं, क्योंकि वे यांत्रिक हैं। तीसरे और चौथे स्तर को रिव्यू से फ़ायदा होता है, क्योंकि वहीं प्रोडक्ट का ज्ञान दाखिल होता है।
हर एंडपॉइंट पर कितने नेगेटिव केस?
हर संभव ख़राब इनपुट गिना देने वाले दस केस से बेहतर हैं एक-दो ऐसे केस जो सचमुच मायने रखते हैं। वे रिजेक्शन चुनें जो कोई असली क्लाइंट ट्रिगर करेगा।
स्टेटस और शेप शुरुआती ज़मीन हैं, पूरा काम नहीं।
API फंक्शनल टेस्टिंग में असर्शन के चार स्तर होते हैं और ज़्यादातर सुइट दूसरे पर ही रुक जाते हैं। डिफ़ेक्ट वैल्यू और रिलेशनशिप असर्शन से पकड़ में आते हैं, और नेगेटिव केस वही है जिसे लोग छोड़ देते हैं।