API इंटीग्रेशन टेस्टिंग को स्पष्ट ग्राफ़ की ज़रूरत क्यों है
| क्रम संयोग पर निर्भर हो जाता है | रनर ने जो क्रम चुन लिया, उसी में टेस्ट पास हो जाते हैं और किसी दूसरी मशीन पर फ़ेल। फिर कोई ऑर्डरिंग प्लगइन जोड़ देता है और समस्या स्थायी हो जाती है। |
| एक फ़ेलियर बीस जैसा दिखता है | create कॉल फ़ेल होती है, उसके आगे का सब कुछ फ़ेल हो जाता है, और स्क्रीन भर लाल रंग मिलता है। पहला असली फ़ेलियर ढूँढना ही पूरा काम बन जाता है। |
| पैरेललिज़्म सुरक्षित नहीं रहता | जब यह पता ही न हो कि क्या किस पर निर्भर है, तो कुछ भी सुरक्षित तरीके से एक साथ नहीं चलाया जा सकता। इसलिए सूट सीरियल और धीमे बने रहते हैं। |
इसे स्पष्ट बनाना
हल यह है कि हर टेस्ट खुद बताए कि उसे क्या चाहिए और वह क्या पैदा करता है। यह जानकारी मौजूद हो जाए, तो रनर उससे एक सुरक्षित क्रम निकाल लेता है, स्वतंत्र ब्रांच समानांतर चलती हैं, और कोई फ़ेलियर अपने ऊपर निर्भर टेस्ट को फ़ेल नहीं, स्किप मार्क करता है। बीस लाल पंक्तियाँ एक फ़ेलियर और उन्नीस स्किप बन जाती हैं, और डीबगिंग का अनुभव पूरी तरह बदल जाता है।
Endpoint Tests और Integration Tests का फ़र्क़ यही है: Endpoint Tests एक बार में एक रूट कवर करते हैं, जबकि Integration Tests कई स्टेप वाली चेन होती हैं जिनमें एक रिस्पॉन्स अगले स्टेप को फ़ीड करता है।
वैल्यू आगे पहुँचाने की समस्या
create कॉल एक आइडेंटिफ़ायर लौटाती है, जिसकी ज़रूरत आगे के स्टेप को होती है। उसे हार्डकोड कर दीजिए, तो टेस्ट ठीक एक बार चलेगा। उसे कैप्चर कीजिए, तो चेन डेटा को सही तरीके से आगे ले जाती है। लिखने में यह मामूली बात लगती है, और पिछले महीने पास हुआ सूट आज फ़ेल क्यों है — इसकी सबसे आम वजह यही अकेली है।
चेन में क्लीनअप
इंटीग्रेशन टेस्ट एंडपॉइंट टेस्ट से ज़्यादा स्टेट बनाते हैं, और उसे ऐसे डिपेंडेंसी क्रम में बनाते हैं जिसका पालन टियरडाउन को भी करना पड़ता है। ऑर्डर से पहले कस्टमर को डिलीट नहीं किया जा सकता। क्लीनअप उसी से जुड़ा हो जो उस रन ने बनाया, और उल्टे डिपेंडेंसी क्रम में चले — कंकरेंसी में सिर्फ़ यही तरीका टिकता है।
कोई API सूट अपना पहला साल निकाल पाएगा या नहीं, यह चार चीज़ें तय करती हैं: सेशन जो एक्सपायर हो जाते हैं, वैल्यू जो सिर्फ़ रनटाइम पर मौजूद होती हैं, कॉल जो एक-दूसरे पर निर्भर होती हैं, और रिकॉर्ड जिन्हें कोई साफ़ नहीं करता। TestSprite इन्हें Auto-Authentication, Dynamic Variables, Dependency Chains और Auto-Cleanup के रूप में संभालता है; इनका विवरण यहाँ है: API टेस्टिंग डॉक्युमेंटेशन।
जब चेन चौथे स्टेप पर फ़ेल हो, तब क्या करें
डिपेंडेंसी घोषित करने का फ़ायदा सबसे साफ़ तब दिखता है जब कोई फ़ेलियर सामने आता है, और उसे किस क्रम में पढ़ना है, यह जान लेना काम आता है।
पहला, देखिए कि गड़बड़ उसी स्टेप में है या उसके इनपुट में। जिस स्टेप को ग़लत आइडेंटिफ़ायर मिला, वह इसलिए फ़ेल हुआ क्योंकि उससे पहले किसी चीज़ ने ग़लत आउटपुट दिया — और उस स्टेप को ठीक करना लक्षण को ठीक करना होगा।
दूसरा, देखिए कि साफ़ स्टेट से चलाने पर भी यह फ़ेल होता है या नहीं। जो चेन एक बार चलती है और दोबारा चलाने पर फ़ेल हो जाती है, वह बता रही है कि क्लीनअप हुआ ही नहीं — यह उस बग से अलग बग है जिसे आप देख रहे थे, और अक्सर उससे ज़्यादा अहम।
तीसरा, इसके बाद ही एंडपॉइंट को देखिए। ज़्यादातर मामलों में काम की जानकारी पहली दो जाँचों में ही मिल जाती है — यही वजह है कि लाल पंक्तियों की सपाट सूची को डीबग करना उस ग्राफ़ के मुक़ाबले कहीं महँगा पड़ता है जिसमें एक फ़ेलियर और उन्नीस स्किप दिखते हैं।
चेन छोटी रखें
बारह स्टेप वाली चेन नौवें स्टेप पर फ़ेल हो जाए, तो वजह पकड़ना मुश्किल और दोबारा चलाना धीमा होता है। एक ही यूज़र इरादे को कवर करने वाले तीन से पाँच स्टेप — यही आकार काम का बना रहता है। लंबी चेन का मतलब आमतौर पर यही होता है कि दो जर्नी आपस में मिला दी गई हैं।
शुरुआत कैसे करें
टर्मिनल
npm install -g @testsprite/testsprite-cli
testsprite setup
अगर आप कुछ भी इंस्टॉल नहीं करना चाहते, तो डैशबोर्ड से भी यही काम हो जाता है। कमांड लाइन और जो कुछ कर सकती है, वह सब यहाँ मिलेगा: CLI रिपॉज़िटरी।
डैशबोर्ड से रिपॉज़िटरी कनेक्ट कीजिए और जो डिप्लॉयमेंट आप पहले से बनाते हैं, रन उसी से शुरू हो जाएँगे; या इसके बजाय अपने वर्कफ़्लो में एक स्टेप जोड़ लीजिए।
TestSprite ग्राफ़ को स्पष्ट कैसे बनाता है
हर केस बताता है कि उसे क्या चाहिए और वह क्या पैदा करता है, और Dependency Chains उसी से एक सुरक्षित एक्ज़ीक्यूशन क्रम निकाल लेती हैं। स्वतंत्र ब्रांच समानांतर चलती हैं, और कुछ फ़ेल होने पर उस पर निर्भर टेस्ट फ़ेल नहीं, स्किप मार्क होते हैं — इसलिए बीस लाल पंक्तियाँ एक फ़ेलियर और उन्नीस स्किप बन जाती हैं।
वैल्यू आगे पहुँचाने का काम Dynamic Variables संभालती हैं, इसलिए चेन वही आइडेंटिफ़ायर आगे ले जाती है जो create कॉल ने लौटाया था, न कि कोई नंबर जो किसी ने चिपका दिया था। Auto-Cleanup हर रन की बनाई चीज़ों को उल्टे डिपेंडेंसी क्रम में हटा देता है, और इसी से एक साथ चलने वाले रन सुरक्षित रहते हैं।
इसका फ़ायदा पहली बार तभी दिखता है जब कोई चेन टूटती है। स्क्रीन भर लाल रंग पढ़ने के बजाय आपको एक फ़ेलियर मिलता है जो बता देता है कि फ़र्क़ कहाँ पड़ा — और यही पाँच मिनट की जाँच और पूरी दोपहर के बीच का फ़र्क़ है।
यह एंड-टू-एंड टेस्टिंग से कैसे अलग है?
एंड-टू-एंड का मतलब आमतौर पर इंटरफ़ेस के ज़रिए टेस्ट करना होता है। API इंटीग्रेशन टेस्टिंग उन्हीं जर्नी को सर्विस लेयर पर चलाती है, जो तेज़ भी है और यह बताने में ज़्यादा सटीक भी कि फ़ेलियर कहाँ हुआ।
क्या इंटीग्रेशन टेस्ट में असली डिपेंडेंसी इस्तेमाल करनी चाहिए?
इंटीग्रेशन टेस्टिंग में हाँ, बात ही यही है। जिसके साथ इंटीग्रेट कर रहे हैं, उसी को मॉक कर देना किसी और सवाल का जवाब देता है।
स्टेप के बीच टेस्ट डेटा कैसे संभालें?
हर स्टेप जो पैदा करता है, उसे कैप्चर कीजिए और आगे भेजिए। साझा सीडेड डेटा तब तक सुविधाजनक है, जब तक दो चेन एक ही रिकॉर्ड को न छूने लगें।
चेन में थर्ड-पार्टी सर्विस का क्या?
जहाँ उनका सैंडबॉक्स मौजूद है, वहाँ उसी का इस्तेमाल कीजिए। जहाँ नहीं है, वहाँ उस स्टेप को अलग कर दीजिए और मान लीजिए कि चेन की एक सीमा है।
हमें कितने इंटीग्रेशन टेस्ट चाहिए?
हर अहम यूज़र जर्नी के लिए एक, न कि हर एंडपॉइंट कॉम्बिनेशन के लिए एक। कॉम्बिनेशन अनगिनत हैं, जर्नी नहीं।
या तो ग्राफ़ घोषित कीजिए, या उसे हमेशा डीबग करते रहिए।
API इंटीग्रेशन टेस्टिंग सीक्वेंस की बात है, और हर सीक्वेंस का एक डिपेंडेंसी ग्राफ़ होता है। हर टेस्ट को क्या चाहिए और वह क्या पैदा करता है — यह घोषित कर देने से सुरक्षित क्रम, पैरेललिज़्म और पढ़ने लायक फ़ेलियर मिलते हैं। वैल्यू हार्डकोड करने के बजाय कैप्चर कीजिए, और चेन छोटी रखिए।