JSONPlaceholder आपको क्या देता है
पूर्वानुमेय रिसोर्स। posts, comments, users, todos और albums — स्थिर identifier और एक जैसी संरचना के साथ।
सभी verb। GET, POST, PUT, PATCH और DELETE — सब समझदारी से जवाब देते हैं।
नेस्टेड संबंध। comments posts के होते हैं, posts users के। अभ्यास करने लायक पर्याप्त संरचना।
वह सबक जो अनजाने में मिलता है
JSONPlaceholder पर लिखने का काम सिर्फ़ नक़ल है। आप POST करते हैं, identifier के साथ 201 मिलता है, और सेव कुछ भी नहीं होता। वापस fetch कीजिए तो वह वहाँ नहीं मिलेगा।
ज़्यादातर लोग इसे एक कमी मानते हैं। दरअसल यह इस सेवा की सबसे उपयोगी बात है, क्योंकि यह उन दो बातों को अलग कर देती है जिन्हें शुरुआती अक्सर एक ही समझ लेते हैं: रिक्वेस्ट सफल हुई और बदलाव सचमुच हुआ। स्टेटस कोड पर assert करने वाला suite यहाँ हर write टेस्ट पास करेगा — पूरे भरोसे के साथ, हमेशा।
अगर आपका assertion JSONPlaceholder के नक़ली writes के बावजूद पास हो जाता है, तो वह कमज़ोर assertion है। उसे दोबारा लिखिए ताकि वह जाँचे कि बाद में वह चीज़ सचमुच मौजूद है या नहीं, और यही आदत अपने असली API तक ले जाइए, जहाँ यही कमज़ोरी दिखाई नहीं देती।
यहाँ किस क्रम में अभ्यास करें
संरचना और फ़ील्ड
स्टेटस के बजाय body की संरचना पर assert कीजिए।
सिर्फ़ मौजूदगी नहीं, टाइप भी जाँचिए।
आपसी संबंध
एक post fetch कीजिए, फिर उसके comments, और जाँचिए कि वे सचमुच उसी post का संदर्भ देते हैं।
असली बग ज़्यादातर दो कॉल के बीच में छिपे होते हैं।
फ़ेल होने के रास्ते
ऐसा identifier माँगिए जो मौजूद ही नहीं है, और assert कीजिए कि रिस्पॉन्स की संरचना सही है।
यही वह टेस्ट है जिसे लोग छोड़ देते हैं, और यही चीज़ें पकड़ता भी है।
यह क्या नहीं सिखा सकता
हर वह चीज़ जिसमें state होती है — यानी वही सब जो असली API टेस्टिंग को मुश्किल बनाता है। सेशन और उनका एक्सपायर होना, एक रिस्पॉन्स से उठाकर अगले में इस्तेमाल होने वाली वैल्यू, ऐसे कॉल जिन्हें तय क्रम में ही चलना है, और रन के बाद की सफ़ाई। JSONPlaceholder में इनमें से कुछ नहीं है, क्योंकि यहाँ कुछ टिकता ही नहीं।
यानी यह पहले एक घंटे के लिए शानदार है और दूसरे हफ़्ते तक आते-आते भ्रम पैदा करने लगता है। बुनियादी बातें सहज लगने लगें, उसी समय असली state वाले किसी API पर चले जाइए — और मान कर चलिए कि मुश्किल एकदम से बढ़ जाएगी।
पहला घंटा, जो आगे काम आए
अगर चाहते हैं कि यह अभ्यास आपके अपने API पर भी काम आए, तो इधर-उधर टटोलने के बजाय ये चार काम इसी क्रम में कीजिए।
एक post fetch कीजिए और सिर्फ़ इतना नहीं कि कॉल सफल हुई — तीन ख़ास फ़ील्ड पर उनके टाइप समेत assert कीजिए। ऐसी post fetch कीजिए जो मौजूद ही नहीं है, और स्टेटस तथा लौटने वाली चीज़ की संरचना, दोनों पर assert कीजिए। एक post fetch कीजिए, फिर उसके comments, और assert कीजिए कि हर comment उसी post का संदर्भ देता है जो आपने माँगी थी। इसके बाद एक post बनाइए, उसे वापस fetch कीजिए, और देखिए कि assertion फ़ेल हो जाता है।
आख़िरी वाला ही पूरे अभ्यास का असल मक़सद है। write ने सफलता बताई, identifier भी लौटा, और टिका कुछ नहीं। असली API तक ले जाने लायक हर आदत बस इसी में है — यह समझने में कि फिर भी आपका टेस्ट पास क्यों हुआ, और उसे इस तरह दोबारा लिखने में कि वह पास न हो।
असली सेवा की ओर बढ़ना
यही चार चीज़ें हैं जिन्हें इसी काम के लिए बनी एक परत Auto-Authentication, Dynamic Variables, Dependency Chains और Auto-Cleanup के रूप में सँभालती है। इसकी पूरी कार्यप्रणाली के लिए देखें API टेस्टिंग डॉक्यूमेंटेशन।
टर्मिनल
npm install -g @testsprite/testsprite-cli
testsprite setup
जिन्हें लोकल इंस्टॉल नहीं चाहिए, उनके लिए डैशबोर्ड भी यही सब कवर करता है, और कमांड का पूरा ब्यौरा देखें CLI रिपॉज़िटरी।
जब आप इसे किसी असली API पर लगाते हैं, तब क्या बदलता है
JSONPlaceholder जो कुछ नहीं सिखा सकता, TestSprite उसी को सँभालता है। रन के बीच में एक्सपायर हो जाने वाले सेशन के लिए Auto-Authentication। create कॉल से लौटने वाले identifier के लिए Dynamic Variables। ऐसे कॉल के लिए Dependency Chains जो तब तक नहीं चल सकते जब तक कुछ और पूरा न हो जाए। हर रन के पीछे छूट जाने वाले रिकॉर्ड के लिए Auto-Cleanup।
शुरुआत वही है जो ऊपर के अभ्यास में थी: एक प्रोजेक्ट को अपने base URL पर लगाइए, API Discovery को गिनने दीजिए कि क्या-क्या मौजूद है, और कुछ भी चलाने से पहले बनी हुई प्लान पढ़िए। फ़र्क़ बस इतना है कि अब यह प्लान ऐसी सेवा पर authorization और सीमा वाली स्थितियों को भी कवर करता है जहाँ writes सचमुच टिकते हैं।
इससे आपको वही मिलता है जिसकी ओर यह पूरा अभ्यास ले जा रहा था: ऐसे assertion जो state के सामने भी टिकते हैं, और जो तब नहीं चलते जब आपको याद आए, बल्कि हर बदलाव पर चलते हैं।
मेरी POST रिक्वेस्ट सेव क्यों नहीं होतीं?
यह जान-बूझकर ऐसा ही है। JSONPlaceholder writes की सिर्फ़ नक़ल करता है। इसे एक सबक की तरह लीजिए — रिस्पॉन्स पर नहीं, नतीजों पर assert करना सीखिए।
क्या यह CI के लिए ठीक है?
ट्यूटोरियल वाले suite के लिए, कभी-कभार। हर commit पर चलने वाली किसी भी चीज़ के लिए इसकी जगह लोकल mock इस्तेमाल कीजिए। यह एक मुफ़्त साझा सेवा है।
इसके बाद किस पर जाना चाहिए?
ऐसी किसी चीज़ पर जिसमें authentication हो और डेटा सचमुच टिकता हो। मुश्किल का यह एकदम बढ़ जाना ही असल बात है, और आगे काम आने वाला कौशल वहीं से शुरू होता है।
क्या इस पर कोई टेस्ट जनरेटर लगाया जा सकता है?
हाँ, और यह देखने के लिए यह सुरक्षित जगह है कि अपने-आप बना कवरेज कैसा दिखता है, क्योंकि यहाँ गंदा करने को कुछ है ही नहीं।
क्या इसके विकल्प भी हैं?
जान-बूझकर फ़ेल कराने और स्टेटस कोड के लिए HTTPBin, बड़े पैमाने पर pagination के लिए PokeAPI, और authentication वाले व्यवहार के लिए कोई सार्वजनिक GitHub API।
यहाँ का सबसे अच्छा सबक इसके नक़ली writes ही हैं।
JSONPlaceholder बिना किसी जोखिम के रिक्वेस्ट की संरचना, आपसी संबंध और फ़ेल होने के रास्ते सिखाता है। इसके नक़ली writes सफल रिक्वेस्ट और असली बदलाव के बीच का फ़र्क़ उजागर कर देते हैं — यही आदत आगे ले जाने लायक है। बुनियादी बातें समझ आ जाएँ, तो state वाले किसी API पर बढ़ जाइए।