API testing के भीतर छिपे पाँच काम
फ़ंक्शनल। क्या एक endpoint सही काम करता है, ख़राब input के साथ भी। शुरुआत यहीं से करें। बाकी सब कुछ इसी को मानकर चलता है।
इंटीग्रेशन। क्या कॉल के क्रम मिलकर सही नतीजा देते हैं। यूज़र को दिखने वाले ज़्यादातर bugs असल में यहीं होते हैं।
कॉन्ट्रैक्ट। क्या दो services ढाँचे पर सहमत हैं। स्वतंत्र deployments के साथ उपयोगी, पर शुद्धता के मामले में अंधा।
बाकी दो हैं लोड, जो क्षमता का जवाब देता है और जिसके लिए एक अलग generator चाहिए, और सुरक्षा-व्यवहार, जो ज़्यादातर authorization की जाँचें ही हैं और जिनकी जगह किसी तिमाही कवायद के बजाय फ़ंक्शनल कवरेज के साथ-साथ है।
इन्हें किस क्रम में करना ठीक रहता है
फ़ंक्शनल, उन endpoints पर जो मायने रखते हैं। नेगेटिव cases समेत। बाकी सब कुछ इसी पर खड़ा होता है।
इंटीग्रेशन, आपकी असली user journeys पर। हर एक में तीन से पाँच steps, बारह नहीं।
हर जगह authorization की जाँच। सस्ता पड़ता है, और object-level authorization सबसे ज़्यादा exploit की जाने वाली API खामी है।
कॉन्ट्रैक्ट, अगर services अलग-अलग deploy होती हैं। अगर आप सब कुछ एक साथ deploy करते हैं तो इसे छोड़ दें।
लोड, releases से पहले। सबसे आख़िर में, क्योंकि ग़लत endpoint पर load testing करना यह नापता है कि आप कितनी तेज़ी से ग़लत हो सकते हैं।
चार समस्याएँ, tool चाहे कोई भी चुनें
चार चीज़ें तय करती हैं कि कोई API suite अपना पहला साल निकाल पाएगी या नहीं: sessions जो ख़त्म हो जाते हैं, वे मान जो सिर्फ़ runtime पर बनते हैं, एक-दूसरे पर निर्भर कॉल, और वे records जिन्हें कोई साफ़ नहीं करता। TestSprite इन्हें Auto-Authentication, Dynamic Variables, Dependency Chains और Auto-Cleanup के रूप में सँभालता है, जिनका वर्णन API testing डॉक्युमेंटेशनमें है।
हर टीम इनसे इसी क्रम में टकराती है और ज़्यादातर टीमें अचानक टकराती हैं। शुरू से इन्हें ध्यान में रखकर डिज़ाइन करना ही टिकने वाली suite और quarantine में डाल दी जाने वाली suite के बीच का फ़र्क़ है।
सबसे ज़्यादा मायने रखने वाला assertion
सिर्फ़ status पर नहीं, body पर assert करें। जहाँ एक record होना चाहिए वहाँ खाली list लेकर आता 200 एक bug है, जिसे status की जाँच पास बता देती है। यह एक आदत किसी भी दूसरे अकेले बदलाव से ज़्यादा असली defects पकड़ती है।
पहले दस cases, ठोस रूप में
अगर suite खाली है, तो सबसे मुश्किल हिस्सा यह तय करना है कि शुरुआत कहाँ से हो, और कोई सामान्य-सा जवाब पूरा हफ़्ता बर्बाद करा देता है। यह रही एक सूची जो ज़्यादातर products के लिए काम करती है।
तीन उस मुख्य object के लिए जिसके इर्द-गिर्द आपका product है: उसे बनाएँ, वापस fetch करके fields पर assert करें, उसे delete करें और पुष्टि करें कि वह हट गया। दो authorization के लिए: वही fetch बिना credentials के, और किसी दूसरे user के credentials के साथ। दो input के लिए: एक ज़रूरी field ग़ायब, और एक मान जो दायरे से बाहर हो। दो उस क्रम के लिए जो release से पहले आपको बेचैन करता है, आपके लिए वह जो भी हो। एक उस endpoint के लिए जो पिछली बार टूटा था।
दस cases, एक सुबह का काम, और ये उन्हीं आकृतियों को कवर करते हैं जिनसे ज़्यादातर incidents पैदा होते हैं। इसके आगे विस्तार किसी कवरेज लक्ष्य से नहीं, बल्कि इससे तय होना चाहिए कि असल में ग़लत क्या हो रहा है, क्योंकि दूसरा तरीक़ा ऐसी suites बनाता है जो बड़ी तो होती हैं पर मुद्दे से परे।
आज शुरुआत कहाँ से करें
एक project को अपनी service पर लगाएँ, discovery को गिनने दें कि क्या-क्या मौजूद है, और कुछ भी चलाने से पहले बनी हुई plan पढ़ें। यह plan आपके API के बारे में पहले नतीजों से ज़्यादा बताती है, और यही वह जगह है जहाँ आपका product-ज्ञान जुड़ता है।
टर्मिनल
npm install -g @testsprite/testsprite-cli
testsprite setup
अगर आप कुछ भी install नहीं करना चाहते, तो dashboard से भी यही काम हो जाता है। कमांड लाइन जो कुछ और कर सकती है, वह सब CLI रिपॉज़िटरीमें है।
GitHub App एक webhook है जिसे आप TestSprite dashboard में सेट करते हैं। यह उसी deployment event को सुनता है जो आपकी pipeline पहले से पैदा करती है, इसलिए आपकी रिपॉज़िटरी में कुछ नहीं बदलता।
GitHub Actions इस step को आपके अपने workflow के भीतर रखता है, जिसे terminal से configure किया जाता है।
इन पाँचों में TestSprite कहाँ बैठता है
फ़ंक्शनल, इंटीग्रेशन और सुरक्षा का व्यवहार वाला आधा हिस्सा। यह चल रही service को परखता है, एक discovery pass और आपके specification से plans बनाता है, और उन नेगेटिव cases को कवर करता है जिन्हें हाथ से लिखी suites छोड़ देती हैं।
Auto-Authentication पूरे run के दौरान sessions ज़िंदा रखता है, Dynamic Variables एक कॉल से दूसरी कॉल तक मान ले जाते हैं, Dependency Chains यह देखकर execution का क्रम निकालते हैं कि हर case को क्या चाहिए और वह क्या पैदा करता है, और Auto-Cleanup ठीक वही हटाता है जो उस run ने बनाया था। किसी भी tool में यही चार चीज़ें तय करती हैं कि कोई suite अपना पहला साल निकालेगी या नहीं, और इनका product के रूप में मौजूद होना ही suite को आगे बढ़ाने और उसे बनाए रखने में लगे रहने के बीच का फ़र्क़ है।
कॉन्ट्रैक्ट testing और लोड अलग औज़ार बने रहते हैं, और यह दोनों के साथ-साथ चलता है। आपको वह परत मिलती है जहाँ यूज़र को दिखने वाले ज़्यादातर defects रहते हैं — अपना कोई framework बनाए बिना कवर, और हर pull request पर चलती हुई।
हमें कितने कवरेज की ज़रूरत है?
उन journeys को कवर करें जिनका टूटना आपके लिए शर्मिंदगी होगी, साथ ही हर वह endpoint जो पैसे या permissions को छूता है। किसी प्रतिशत की ओर बढ़ने के बजाय incidents से आगे बढ़ें।
क्या हमें production पर टेस्ट करना चाहिए?
एक प्रतिनिधि environment पर करें। किसी test suite को संतुष्ट करने के लिए production में records बनाना और मिटाना अपने साथ जोखिम लाता है।
क्या हमें specification चाहिए?
इससे मदद मिलती है, पर यह ज़रूरी नहीं। चल रही service पर एक discovery pass और एक requirements दस्तावेज़ मिलकर आपको काम लायक plan दे देते हैं।
mocking का क्या?
उन third parties को mock करें जो आपके नियंत्रण में नहीं हैं। अपनी ही service को mock करने का मतलब है mock को टेस्ट करना।
suite कितनी बार चलनी चाहिए?
फ़ंक्शनल और इंटीग्रेशन के लिए हर pull request पर, लोड के लिए एक तय schedule पर। हफ़्ते में एक बार चलने वाली suite समस्याएँ एक हफ़्ता देर से पकड़ती है।
पाँच काम, एक क्रम।
API testing का मतलब है फ़ंक्शनल, इंटीग्रेशन, कॉन्ट्रैक्ट, लोड और सुरक्षा-व्यवहार। पहले फ़ंक्शनल और इंटीग्रेशन करें, हर जगह authorization की जाँच जोड़ें, और sessions, पकड़े गए मानों, क्रम और cleanup को शुरू से ही ध्यान में रखकर डिज़ाइन करें।