Cypress API testing वाक़ई किन चीज़ों में अच्छा है
सेटअप और teardown। पाँच स्क्रीन पर क्लिक करने के बजाय UI टेस्ट को जिस state की ज़रूरत है, उसे API के ज़रिए बना देना। तेज़, ज़्यादा भरोसेमंद, और इस क्षमता का सही इस्तेमाल।
क्रॉस-लेयर assertions। इंटरफ़ेस में कुछ कीजिए, फिर पुष्टि कीजिए कि बैकएंड ने उसे सही ढंग से दर्ज किया। यह एक असली श्रेणी है और Cypress इसे बख़ूबी संभालता है।
गिनी-चुनी endpoint जाँचें। जब API सरफ़ेस छोटा हो, तो सरलता के बदले उसे उसी सुइट में रखना एक वाजिब सौदा है।
स्केल के साथ आने वाली चार समस्याएँ
सेशन की अवधि
सुइट के बीच में ही टोकन एक्सपायर हो जाते हैं और फ़ेल्योर प्रोडक्ट बग जैसे दिखते हैं।
रिफ़्रेश लॉजिक आख़िरकार किसी support फ़ाइल में हाथ से लिखना पड़ता है।
कॉल्स के बीच वैल्यूज़
create कॉल से मिला identifier delete कॉल तक पहुँचना चाहिए, और Cypress की command chaining इसे अलग-अलग टेस्ट के बीच बोझिल बना देती है।
लोग वैल्यू hardcode कर देते हैं, और सुइट एक बार चल जाता है।
क्रम
असली API कवरेज एक ग्राफ़ है, जबकि टेस्ट फ़ाइलें एक सूची। उस ग्राफ़ को हाथ से कोड करने में ही सारा मेंटेनेंस खप जाता है।
चौथी है क्लीनअप। रिकॉर्ड जमा होते जाते हैं, uniqueness constraints चलने लगते हैं, और डेटा बढ़ने के साथ pagination से जुड़े assertions खिसकने लगते हैं।
ये असल में Cypress की समस्याएँ क्यों नहीं हैं
Cypress को ब्राउज़र-चालित टेस्ट लाइफ़साइकल के इर्द-गिर्द बनाया गया था। ऊपर जो कुछ भी है, वह उस state के बारे में है जो किसी एक टेस्ट और किसी एक रन के बाहर रहती है। आप यह सब support फ़ाइलों में हल कर सकते हैं, और तब वह हल ख़ुद एक छोटा फ़्रेमवर्क बन जाता है जिसे किसी न किसी को मेंटेन करना पड़ता है — यही वह लागत है जिसकी योजना कोई नहीं बनाता।
इसके बदले ख़ास इसी काम के लिए बनी API लेयर क्या संभालती है
आप कोई भी टूल इस्तेमाल करें, चार चीज़ें तय करती हैं कि कोई API सुइट अपना पहला साल निकाल पाएगा या नहीं: सेशन जो एक्सपायर हो जाते हैं, वैल्यूज़ जो सिर्फ़ रनटाइम पर मौजूद होती हैं, कॉल्स जो एक-दूसरे पर निर्भर होती हैं, और रिकॉर्ड जिन्हें कोई साफ़ नहीं करता। TestSprite इन्हें Auto-Authentication, Dynamic Variables, Dependency Chains और Auto-Cleanup कहता है, और API testing डॉक्यूमेंटेशन इनकी कार्यप्रणाली विस्तार से बताता है।
जहाँ support फ़ाइल एक फ़्रेमवर्क बन जाती है
एक पहचानने लायक़ मोड़ आता है जहाँ Cypress के भीतर का API सुइट चंद रिक्वेस्ट भर नहीं रह जाता और इंफ़्रास्ट्रक्चर बन जाता है; इसे नाम देना ज़रूरी है ताकि आप बहते चले जाने के बजाय सोच-समझकर फ़ैसला ले सकें।
शुरुआत होती है support फ़ाइल में एक login कमांड से। फिर एक टोकन कैश, क्योंकि हर टेस्ट के लिए लॉगिन करना धीमा है। फिर रिफ़्रेश लॉजिक, क्योंकि रन के बीच में ही कैश बासी हो जाता है। फिर एक हेल्पर जो बनाए गए identifiers सहेजता है ताकि बाद के टेस्ट उन्हें ढूँढ़ सकें, फिर फ़ाइल नामों में क्रम तय करने की परंपराएँ, और फिर एक क्लीनअप टास्क जो सुइट के बाद चलता है और इन सबके बारे में जानता है।
इनमें से कोई क़दम ग़लत नहीं है और हर क़दम अगला ज़ाहिर क़दम ही लगता है। नतीजा यह होता है कि support डायरेक्टरी में कुछ सौ लाइनों का एक फ़्रेमवर्क बैठा है, जिसे सिर्फ़ एक व्यक्ति समझता है, और जो उस रनर के दायरे से बाहर है जिस पर वह खड़ा हुआ था। इस दिशा को जल्दी पहचान लेना ही इसे बयान करने का पूरा फ़ायदा है।
बाँटने का वह तरीक़ा जिसे अपनाना चाहिए
बनाए रखें cy.request को सेटअप, teardown और उन क्रॉस-लेयर assertions के लिए जिनमें सचमुच एक ही टेस्ट के भीतर दोनों परतें चाहिए। स्टैंडअलोन endpoint और integration कवरेज को ऐसी लेयर पर ले जाइए जो इन चार समस्याओं को आपका होमवर्क नहीं, बल्कि अपने काम का हिस्सा मानती है।
दोनों सुइट्स को एक-दूसरे के बारे में जानने की ज़रूरत नहीं है, और दोनों एक ही पाइपलाइन से चल सकते हैं।
मैकेनिज़्म से ज़्यादा मायने ट्रिगर रखता है। इसे अपने डिप्लॉयमेंट इवेंट से जोड़ देने का मतलब है कि हर बदलाव की जाँच हो जाती है, बिना किसी के अलग से तय किए; GitHub App डैशबोर्ड से यही करता है, और एक GitHub Actions स्टेप इसे आपके वर्कफ़्लो के भीतर से करता है। विस्तृत जानकारी के लिए देखें CLI रिपॉज़िटरी।
आपको अब क्या मेंटेन नहीं करना पड़ता
ऊपर बताया गया support-फ़ाइल वाला फ़्रेमवर्क ही वह चीज़ है जिसकी जगह TestSprite लेता है। Auto-Authentication सेशन की अवधि संभालता है। Dynamic Variables किसी identifier को create कॉल से delete कॉल तक पहुँचाते हैं। Dependency Chains हर केस को जो चाहिए और जो वह पैदा करता है, उससे एक सुरक्षित क्रम निकाल लेते हैं। Auto-Cleanup ठीक वही हटाता है जो उस रन ने बनाया था, और यही समानांतर एक्ज़ीक्यूशन को सुरक्षित बनाता है।
कवरेज अब इस पर भी निर्भर नहीं रहती कि किसके पास समय है। प्लान किसी स्पेसिफ़िकेशन से या चल रही सर्विस पर एक discovery पास से बनते हैं — उन error paths और boundary values समेत जो हाथ से कभी लिखे ही नहीं जाते — और सादी भाषा में उन्हें निखारा जाता है।
Cypress के पास वही रहता है जिसमें वह अच्छा है: सेटअप, teardown और वे क्रॉस-लेयर जाँचें जहाँ आपको सचमुच एक ही टेस्ट में ब्राउज़र और API दोनों चाहिए। दोनों एक ही पाइपलाइन से चलते हैं, एक-दूसरे के बारे में जाने बिना।
क्या cy.request ख़राब तरीक़ा है?
बिल्कुल नहीं। सेटअप और क्रॉस-लेयर जाँचों के लिए यही सही टूल है। सीमा स्केल की है, सहीपन की नहीं।
क्या हम सब कुछ Cypress में ही रख सकते हैं?
रख सकते हैं, और तब सेशन हैंडलिंग, वैल्यू कैप्चर, क्रम और क्लीनअप — सब ख़ुद मेंटेन करना पड़ेगा। छोटे सरफ़ेस के लिए यह सौदा ठीक है, उससे आगे महँगा।
Cypress component testing का क्या?
इस सब से उस पर कोई असर नहीं पड़ता। कंपोनेंट टेस्ट एक अलग सवाल का जवाब देते हैं और उन्हें जहाँ हैं वहीं रखना सबसे अच्छा है।
डुप्लिकेट कवरेज से कैसे बचें?
सवाल के हिसाब से बाँटिए। Cypress यह बताता है कि यूज़र को दिखने वाला फ़्लो काम करता है या नहीं। API लेयर यह बताती है कि endpoints सही बर्ताव करते हैं या नहीं। अगर कोई टेस्ट दोनों जगह पास होगा, तो उसकी जगह सस्ती वाली है।
क्या API लेयर को हमारे सोर्स कोड की ज़रूरत है?
नहीं। वह चल रही सर्विस पर काम करती है, और क्या-क्या मौजूद है यह जानने के लिए किसी स्पेसिफ़िकेशन या एक discovery पास का इस्तेमाल करती है।
cy.request को सेटअप के लिए रखिए, पूरे API सुइट के लिए नहीं।
Cypress API testing fixtures और क्रॉस-लेयर assertions के लिए बेहतरीन है। लेकिन जैसे ही स्टैंडअलोन API कवरेज बढ़ती है, सेशन, कैप्चर की गई वैल्यूज़, क्रम और क्लीनअप मिलकर एक ऐसा फ़्रेमवर्क बन जाते हैं जिसे आप हाथ से मेंटेन करते हैं — और यही वह पल है जब उस लेयर को कहीं ऐसी जगह ले जाना चाहिए जो इसी के लिए बनी हो।