REST API टेस्टिंग की शुरुआत स्टेटस कोड के सिमेंटिक्स से होती है
REST स्टेटस कोड को एक अर्थ देता है और क्लाइंट उसी अर्थ पर निर्भर रहते हैं। इसे मान लेने के बजाय साफ़ तौर पर assert करना बेहतर है।
क्रिएट करने पर location के साथ 201, न कि 200 जिसमें बस एक बॉडी हो और कुछ नहीं।
जो मौजूद नहीं है उसके लिए 404, जो वर्जित है उसके लिए 403। forbidden के लिए 404 लौटाना कुछ टीमों का सोचा-समझा फ़ैसला होता है; लेकिन जो मौजूद ही नहीं है उसके लिए 403 लौटाना सिर्फ़ एक बग है।
अमान्य इनपुट के लिए 422 या 400, और लगातार एक जैसा। एक चुनें और जाँचें कि हर एंडपॉइंट उसी पर टिका है।
बॉडी के अंदर एरर के साथ 200 कभी नहीं। यह आम है, और इसकी वजह से हर क्लाइंट को अलग से विशेष हैंडलिंग लिखनी पड़ती है।
Idempotency
PUT और DELETE को idempotent होना चाहिए। इन्हें दो बार कॉल करने पर स्टेट वही रहनी चाहिए और दूसरी बार कोई एरर नहीं आना चाहिए। यहाँ ग़लती होना आसान है और जाँचना भी उतना ही आसान: दो बार कॉल करें और assert करें।
यही बात दूसरे DELETE पर लागू होती है — उसे 500 नहीं, 404 लौटाना चाहिए। क्लाइंट रीट्राई करते हैं, और रीट्राई के लिए असुरक्षित एंडपॉइंट नेटवर्क की एक छोटी-सी रुकावट को यूज़र को दिखने वाली फ़ेल्योर में बदल देता है।
वे कन्वेंशन जिनका दावा आपकी सर्विस करती है
| पेजिनेशन | क्या पूरी लिस्ट ट्रैवर्स करने पर उतने ही रिकॉर्ड मिलते हैं जितने कलेक्शन बताता है। पेज की सीमाओं पर एक-कम-एक-ज़्यादा की ग़लती बेहद आम है। |
| फ़िल्टरिंग और सॉर्टिंग | क्या अनजान फ़िल्टर रिजेक्ट होता है या चुपचाप नज़रअंदाज़ कर दिया जाता है। चुपचाप नज़रअंदाज़ करने पर पूरे भरोसे के साथ ग़लत डेटा लौटता है। |
| पार्शियल अपडेट | क्या PATCH सिर्फ़ उसी को बदलता है जो भेजा गया था, या बाकी को चुपचाप null कर देता है। |
इन सबके नीचे छिपी जाँच
सिर्फ़ स्टेटस पर नहीं, बॉडी पर assert करें। जहाँ एक रिकॉर्ड होना चाहिए, वहाँ खाली लिस्ट के साथ आया 200 अब तक लिखे गए हर स्टेटस assertion को पास कर जाएगा। यह अकेली आदत REST API टेस्टिंग में किसी भी कन्वेंशन-जाँच से ज़्यादा असली डिफ़ेक्ट पकड़ती है।
चार समस्याएँ
चार चीज़ें तय करती हैं कि कोई API सूट अपना पहला साल निकाल पाएगा या नहीं: सेशन जो एक्सपायर हो जाते हैं, वैल्यू जो सिर्फ़ रनटाइम पर मौजूद होती हैं, कॉल जो एक-दूसरे पर निर्भर होते हैं, और रिकॉर्ड जिन्हें कोई साफ़ नहीं करता। TestSprite इन्हें Auto-Authentication, Dynamic Variables, Dependency Chains और Auto-Cleanup के रूप में संभालता है; इनका विवरण यहाँ दिया गया है: API टेस्टिंग डॉक्यूमेंटेशन।
वे कन्वेंशन जिन्हें सबसे पहले लिख लेना चाहिए
इससे पहले कि आप यह टेस्ट करें कि आपका API अपने कन्वेंशन का पालन करता है या नहीं, किसी को यह तय करके बताना होगा कि वे कन्वेंशन हैं क्या — और ज़्यादातर टीमों को इसी कसरत के दौरान पता चलता है कि उनके बीच सहमति नहीं है।
चार सवाल इसका ज़्यादातर हिस्सा तय कर देते हैं। क्रिएट करने पर कौन-सा स्टेटस लौटता है, और क्या उसमें location होता है। जब कॉलर को किसी भी सूरत में वह रिसोर्स देखने की अनुमति नहीं है, तो न मिलने वाला रिसोर्स 404 है या 403। अनजान क्वेरी पैरामीटर रिजेक्ट होता है या नज़रअंदाज़। PATCH ग़ायब फ़ील्ड को अपरिवर्तित मानता है या null।
इनमें से किसी का भी कोई सार्वभौमिक रूप से सही जवाब नहीं है, और ये सभी ऐसे फ़ैसले हैं जिन पर आपके क्लाइंट निर्भर करते हैं। इन चार जवाबों को लिख लेने में बीस मिनट लगते हैं, और इससे RESTful होने का धुंधला इरादा ऐसी चीज़ बन जाता है जिस पर आप सच में assert कर सकें — और यही किसी भी चीज़ के टेस्ट होने की पहली शर्त है।
सब कुछ ख़ुद लिखे बिना कवरेज पाना
जेनरेट किए गए प्लान किसी स्पेसिफ़िकेशन या डिस्कवरी पास के आधार पर फ़ंक्शनल, स्कीमा, ऑथराइज़ेशन, एरर-हैंडलिंग और बाउंड्री श्रेणियों को कवर करते हैं, जिनमें ऊपर बताई गई ज़्यादातर कन्वेंशन-जाँचें डिफ़ॉल्ट रूप से शामिल रहती हैं।
टर्मिनल
npm install -g @testsprite/testsprite-cli
testsprite setup
अगर आप कुछ भी इंस्टॉल नहीं करना चाहते, तो डैशबोर्ड भी यही काम करता है। कमांड लाइन जो कुछ और कर सकती है, वह सब यहाँ है: CLI रिपॉज़िटरी।
अगर पाइपलाइन किसी दूसरी टीम की है, तो GitHub App सबसे कम रुकावट वाला रास्ता है: यह एक webhook है, यह आपकी रिपॉज़िटरी में कुछ नहीं बदलता, और तब चलता है जब आपका बिल्ड नए वर्ज़न के लाइव होने की रिपोर्ट करता है। अगर आप चाहते हैं कि यह चेक रिपॉज़िटरी में ही दिखे, तो GitHub Actions स्टेप यही काम कर देता है।
TestSprite इन कन्वेंशन को कैसे जाँचता है
जेनरेट किए गए प्लान चल रही सर्विस पर फ़ंक्शनल, स्कीमा, ऑथराइज़ेशन, एरर-हैंडलिंग और बाउंड्री श्रेणियों को कवर करते हैं, जिनमें ऊपर बताई गई ज़्यादातर कन्वेंशन-जाँचें आ जाती हैं: हर ऑपरेशन के लिए स्टेटस सिमेंटिक्स, ख़राब इनपुट का रिजेक्ट होना, न मिलने वाले रिसोर्स पर व्यवहार, और पेजिनेशन का हिसाब सही बैठना।
Auto-Authentication पूरे रन के दौरान सेशन ज़िंदा रखता है, Dynamic Variables एक कॉल की वैल्यू दूसरी तक पहुँचाता है, Dependency Chains इससे एक्ज़ीक्यूशन का क्रम निकालता है कि हर केस को क्या चाहिए और वह क्या पैदा करता है, और Auto-Cleanup ठीक वही हटाता है जो उस रन ने बनाया था। आख़िरी बात REST के लिए लोगों की उम्मीद से ज़्यादा मायने रखती है, क्योंकि idempotency की जाँच का मतलब ही है एक ही डिस्ट्रक्टिव ऑपरेशन को जान-बूझकर दो बार कॉल करना।
इससे आपको यह मिलता है कि आपके अपने कन्वेंशन सिर्फ़ डॉक्यूमेंट करके उम्मीद पर नहीं छोड़े जाते, बल्कि हर बदलाव पर उन पर assert होता है — और यही वह चीज़ है जो एक एंडपॉइंट को चुपचाप 200 लौटाने से रोकती है, जबकि बाकी सब 201 लौटाते हैं।
क्या टेस्टिंग के लिए REST की शुद्धता मायने रखती है?
सिर्फ़ वहाँ, जहाँ क्लाइंट उस पर निर्भर हों। उन कन्वेंशन को टेस्ट करें जिनका पालन करने का दावा आपकी सर्विस करती है, न कि उन्हें जो कोई किताब बताती है।
HATEOAS को कैसे टेस्ट करें?
अगर आप लिंक लौटाते हैं, तो assert करें कि वे रिज़ॉल्व होते हैं और वहीं ले जाते हैं जहाँ का वे दावा करते हैं। अगर नहीं लौटाते, तो इसे छोड़ दें; बहुत कम सर्विसेज़ इसे सच में लागू करती हैं।
और GraphQL का क्या?
इसके कन्वेंशन पूरी तरह अलग हैं। यहाँ स्टेटस कोड बहुत कम अर्थ रखते हैं और एरर डिज़ाइन के हिसाब से बॉडी में आते हैं, इसलिए ऊपर बताई गई जाँचें ज़्यादातर लागू नहीं होतीं।
क्या रिस्पॉन्स हेडर जाँचने चाहिए?
कंटेंट टाइप हमेशा। कैशिंग और रेट लिमिट हेडर तभी, जब क्लाइंट उन पर कोई कार्रवाई करते हों — और उन पर assert करने से पहले यह जान लेना ज़रूरी है।
क्या वर्ज़निंग को टेस्ट करना ज़रूरी है?
हाँ, अगर आप एक से ज़्यादा वर्ज़न सपोर्ट करते हैं। assert करें कि पुराना वर्ज़न आज भी वैसा ही व्यवहार करता है जैसा पहले करता था, क्योंकि वर्ज़न नंबर यही वादा करता है।
अपने API के किए हुए वादों को टेस्ट करें।
REST API टेस्टिंग को उन कन्वेंशन की पुष्टि करनी चाहिए जिनका दावा आपकी सर्विस करती है: स्टेटस सिमेंटिक्स, idempotency, पेजिनेशन के कुल आँकड़े, और यह कि अनजान फ़िल्टर रिजेक्ट होते हैं या नहीं। इन सबके नीचे, स्टेटस पर नहीं, बॉडी पर assert करें।