Selenium के साथ API testing की बात आख़िर उठती ही क्यों है
तीन वजहें हैं, और उनमें से सिर्फ़ एक ठीक है।
Suite पहले से मौजूद है। CI में Selenium का job पहले से है, लोग उसे चलाना जानते हैं, और API checks वहीं जोड़ देना सबसे आसान रास्ता लगता है। यह समझ में आता है, पर यह तकनीकी वजह नहीं, संगठन से जुड़ी वजह है।
Flow दोनों तक फैला हुआ है। एक form submit कीजिए, फिर जाँचिए कि API ने जो record बनाया वह सही है। यह वजह जायज़ है और इसी के लिए डिज़ाइन करना सार्थक है।
Setup और teardown। API के ज़रिये fixtures बनाना, क्योंकि interface से यह करना धीमा पड़ता है। समझदारी की बात है, हालाँकि यह testing नहीं, बस ढाँचा तैयार करना है।
इसकी कीमत क्या है
| धीमा feedback | जो जाँच बस एक request भर हो सकती थी, उसमें ज़्यादातर समय browser के शुरू होने में चला जाता है। बीस मिनट लेने वाली suite कम बार चलाई जाती है, और असली नुकसान यही है। |
| उलझी हुई failures | जब कोई मिला-जुला test fail होता है तो आपको पता लगाना पड़ता है कि गड़बड़ interface में हुई या API में। अलग-अलग suites यह जवाब मुफ़्त में दे देती हैं। |
| UI के हिसाब से बनी coverage | आप उन्हीं endpoints को cover करते रह जाते हैं जिन्हें interface संयोग से call करता है, और वे पूरी सतह का छोटा-सा हिस्सा हैं। Error codes और किनारे के parameters की कभी जाँच ही नहीं होती। |
वह बँटवारा जो काम करता है
Selenium को उसी काम के लिए रखिए जिसका जवाब सिर्फ़ browser दे सकता है: क्या user को दिखने वाला flow चलता है। API को उसके अपने स्तर पर cover कीजिए, जहाँ एक जाँच page load नहीं बल्कि एक request होती है। Selenium suite में से API का इस्तेमाल सिर्फ़ setup और teardown के लिए कीजिए, जहाँ बात रफ़्तार की है और कोई assertion शामिल नहीं होता।
सचमुच दोनों को जोड़ने वाला एक ही मामला है — form submit करके जाँचना कि backend ने क्या store किया — और उसे संयोग से नहीं, सोच-समझकर लिखना चाहिए। ऐसे tests गिनती में थोड़े होते हैं और अपनी कीमत वसूल कर देते हैं।
एक स्वतंत्र API layer को क्या सँभालना पड़ता है
आप कोई भी tool इस्तेमाल करें, चार चीज़ें तय करती हैं कि कोई API suite अपना पहला साल निकाल पाएगी या नहीं: sessions जो expire हो जाते हैं, मान जो सिर्फ़ runtime पर मौजूद होते हैं, calls जो एक-दूसरे पर निर्भर होती हैं, और records जिन्हें कोई साफ़ नहीं करता। TestSprite इन्हें Auto-Authentication, Dynamic Variables, Dependency Chains और Auto-Cleanup नाम देता है, और API testing दस्तावेज़ इनकी कार्यप्रणाली विस्तार से बताता है।
इन चारों को ठीक से सँभाल लेना ही वह फ़र्क़ है जो टिकने वाली suite को उस suite से अलग करता है जिसे दो क्वार्टर बाद delete कर दिया जाता है, और यह काम API के स्तर पर करना किसी browser suite पर थोप देने से कहीं आसान है।
Setup का मामला, ठीक तरीके से
किसी browser test के लिए fixtures बनाने में API का इस्तेमाल करना — यही एक जगह है जहाँ ये दोनों सचमुच साथ बैठते हैं, और इसे संयोग से नहीं, सोच-समझकर करना चाहिए।
इसे साफ़ रखने वाला नियम यह है कि setup calls कभी assert नहीं करतीं। उनका काम है system को जितनी जल्दी हो सके एक जानी-पहचानी स्थिति में ले आना, और अगर कोई नाकाम हो जाए तो test fail नहीं, error होना चाहिए, क्योंकि नाकाम fixture infrastructure की समस्या है, product का दोष नहीं। दोनों को एक मान लेने से ऐसी suite बनती है जिसमें आधे लाल निशान सिर्फ़ शोर होते हैं।
दूसरा नियम यह है कि setup ने जो भी बनाया, teardown उसे हटा दे — उस test से जुड़ा हुआ, नाम से मिलान करके नहीं। Browser suites में data सबकी उम्मीद से ज़्यादा तेज़ी से जमा होता है, और हर हफ़्ते धीमी पड़ती जाने वाली कोई list view आम तौर पर वही teardown होती है जो कभी लिखा ही नहीं गया।
दोनों को चलाना
किसी भी suite को दूसरी के बारे में जानने की ज़रूरत नहीं है। Selenium आपके CI job में वैसे ही चलता रहता है जैसे आज चलता है, और API coverage उसके साथ-साथ चलती है।
अगर pipeline किसी दूसरी टीम के पास है, तो GitHub App सबसे आसान रास्ता है: यह एक webhook है, आपकी repository में कुछ नहीं बदलता, और तब चल पड़ता है जब आपका build बताता है कि नया version live हो गया है। अगर आप चाहते हैं कि यह जाँच इसके बजाय repo में ही दिखे, तो GitHub Actions step यह काम कर देता है। देखिए CLI repository।
TestSprite API के स्तर पर क्या cover करता है
TestSprite स्वतंत्र API layer को सँभाल लेता है, ताकि आपको इसे किसी browser suite पर थोपना न पड़े। API Discovery गिनकर बताता है कि चल रही service क्या-क्या उजागर करती है, plan generation functional, schema, authorization, error-handling और boundary श्रेणियों में cases सुझाता है, और आप उन्हें आम भाषा में सुधार लेते हैं।
state से जुड़ी वे चारों समस्याएँ आपके infrastructure के बजाय product के रूप में मिलती हैं: Auto-Authentication sessions को ज़िंदा रखता है, Dynamic Variables calls के बीच मान ले जाते हैं, Dependency Chains execution का क्रम निकालती हैं, Auto-Cleanup किसी run ने जो बनाया उसे हटा देता है। यही चीज़ें किसी API suite को चलती हालत में रखना मुश्किल बनाती हैं, और इन्हें browser runner के अंदर सुलझाने के मुक़ाबले API के स्तर पर सुलझाना कहीं आसान है।
आपकी Selenium suite जहाँ है वहीं रहती है, और वही cover करती है जिसका जवाब सिर्फ़ browser दे सकता है। दोनों एक ही pipeline से चलती हैं।
क्या Selenium सीधे HTTP requests भेज सकता है?
language bindings के ज़रिये, हाँ, क्योंकि आप तो बस code लिख रहे होते हैं। सवाल यह है कि इसमें browser session को शामिल होना ही चाहिए या नहीं, और शुद्ध API जाँच के लिए जवाब आम तौर पर "नहीं" होता है।
क्या हमें अपनी Selenium suite migrate करनी चाहिए?
पूरी तरह नहीं। जिस Selenium suite पर लोग भरोसा करते हैं, वह एक पूँजी है। कुछ भी इधर-उधर करने के बजाय API coverage को उसके अपने स्तर पर जोड़िए।
दोनों तक फैले हुए flow को कैसे test करें?
उसे सोच-समझकर एक ही test के रूप में लिखिए, ऐसे tests की गिनती कम रखिए, और assertion इतना विशिष्ट रखिए कि fail होने पर पता चल जाए कि गड़बड़ किस तरफ़ हुई।
क्या इसके लिए Playwright बेहतर है?
उसमें first-class request API है, इसलिए तरीका ज़्यादा सुविधाजनक है। ढाँचे को लेकर दलील वही रहती है: browser की जाँच और API की जाँच अलग-अलग सवालों के जवाब देती हैं और इन्हें अलग रखना ही बेहतर है।
दोनों में authentication का क्या?
credential का स्रोत साझा कीजिए, session नहीं। हर layer को अपना session खुद लेना चाहिए, ताकि एक में आई नाकामी दूसरे तक न फैले।
browser से जुड़े सवालों के लिए browser इस्तेमाल कीजिए।
Selenium के साथ API testing का मतलब आम तौर पर यह होता है कि दो तरह की जाँचों में तालमेल बिठाया जाए, न कि एक ही tool से दोनों काम ज़बरदस्ती कराए जाएँ। Selenium को user को दिखने वाले flows के लिए रखिए, API को उसके अपने स्तर पर cover कीजिए, और जो tests सचमुच दोनों को जोड़ते हैं उन्हें जानबूझकर लिखिए।