Python API Testing: requests और pytest से लेकर एक टिकाऊ टेस्ट सुइट तक

Python API testing आमतौर पर कहाँ से शुरू होती है, और इसमें कोई बुराई क्यों नहीं है

requests और pytest छोड़ने के लिए किसी की बात मत मानिए। टेस्ट सामान्य Python होते हैं, fixtures आपस में जुड़ जाते हैं, parametrize boundary values को साफ़-सुथरे ढंग से कवर कर लेता है, और टीम का हर व्यक्ति उसे पढ़ सकता है। अपनी ही किसी सर्विस के इर्द-गिर्द बनी एक केंद्रित suite के लिए यह आज भी बेहतरीन जवाब है।

वे चार चीज़ें जो आगे चलकर काम बन जाती हैं

• सेशन। एक token fixture तब तक काम करता है जब तक वह रन के बीच में एक्सपायर नहीं हो जाता, और फिर आप refresh logic लिख रहे होते हैं और उसे workers के बीच cache कर रहे होते हैं।

• कैप्चर की गई वैल्यूज़। एक कॉल से मिला identifier अगली कॉल में जाता है। जब तक graph चौड़ा नहीं होता, fixtures इसे संभाल लेते हैं; उसके बाद fixture graph ही वह चीज़ बन जाता है जिसे आप मेंटेन करते रहते हैं।

• ऑर्डरिंग। pytest डिपेंडेंसी के हिसाब से क्रम तय नहीं करता। टीमें ordering plugins का सहारा लेती हैं, और शुरुआत में हुई एक अकेली विफलता पूरी स्क्रीन को ग़ैर-संबंधित लाल रंग से भर देती है।

चौथी चीज़ है parallelism के दौरान cleanup। जैसे ही pytest-xdist आ जाता है, नाम के पैटर्न से डिलीट करना सुरक्षित नहीं रह जाता, और teardown को ठीक-ठीक पता होना चाहिए कि हर रन ने क्या बनाया था।

असली क़ीमत

अलग-अलग देखें तो इनमें से कुछ भी मुश्किल नहीं है। मिलकर ये एक इंटरनल फ्रेमवर्क बन जाते हैं: एक ऐसा conftest जिसे कोई छूना नहीं चाहता, एक ऐसा fixture graph जिसे सिर्फ़ एक व्यक्ति समझता है, और एक ऐसी suite जो लाल होने पर ठीक करने के बजाय क्वारंटीन कर दी जाती है। यह नतीजा इतना आम है कि इसे ध्यान में रखकर ही योजना बनानी चाहिए।

ख़ास इसी काम के लिए बनी लेयर क्या संभालती है

आप कोई भी टूल इस्तेमाल करें, चार चीज़ें तय करती हैं कि कोई API suite अपना पहला साल निकाल पाएगी या नहीं: ऐसे sessions जो एक्सपायर हो जाते हैं, ऐसी वैल्यूज़ जो सिर्फ़ रनटाइम पर मौजूद होती हैं, ऐसी कॉल्स जो एक-दूसरे पर निर्भर होती हैं, और ऐसे रिकॉर्ड जिन्हें कोई साफ़ नहीं करता। TestSprite इन्हें Auto-Authentication, Dynamic Variables, Dependency Chains और Auto-Cleanup कहता है, और API testing डॉक्यूमेंटेशन इनकी कार्यप्रणाली विस्तार से बताता है।

कवरेज भी एक अलग जगह से आती है। किसी को जो endpoints याद रह गए उनके बजाय, किसी specification से या चल रही सर्विस पर discovery pass से जेनरेट किया गया प्लान उन error paths और boundary cases को भी शामिल करता है जो हाथ से कभी नहीं लिखे जाते।

अगर आप टेस्ट अपनी रिपॉज़िटरी में ही चाहते हैं

कुछ टीमें चाहती हैं कि suite रिपो में ही रहे और बाक़ी कोड की तरह उसका भी रिव्यू हो — यह एक वाजिब पसंद है। CLI ऐसे बैकएंड टेस्ट सपोर्ट करता है जो Python में लिखे जाते हैं, जहाँ हर टेस्ट के लिए डिपेंडेंसीज़ घोषित की जाती हैं और teardown को अपने अलग केस के रूप में मार्क किया जाता है, ताकि graph fixture nesting से निकला हुआ अनुमान न होकर साफ़-साफ़ दिखे। पूरा विवरण यहाँ देखें — CLI रिपॉज़िटरी.

वह conftest जो पूरी टीम को निगल गया

जो Python suite अपने आकार से बड़ी हो चुकी है, उसकी एक पहचानी-पहचानी शक्ल होती है, और वह एक ही फ़ाइल में बसती है। conftest की शुरुआत एक session fixture और एक base URL से होती है। फिर एक token fixture, फिर एक cache ताकि हर टेस्ट पर token न लाना पड़े, फिर एक lock क्योंकि xdist workers उसी cache पर आपस में टकरा रहे थे। फिर factories, फिर एक registry ताकि teardown को पता रहे कि क्या हटाना है, फिर ordering markers क्योंकि कुछ factories दूसरों पर निर्भर हैं।

हर क़दम अलग से देखने पर सही है, और नतीजा छह सौ लाइनें हैं जिन्हें सिर्फ़ एक व्यक्ति समझता है। पहचान तब होती है जब कोई कहता है कि एक टेस्ट फेल हो रहा है और पहला सवाल यही उठता है कि कहीं conftest तो नहीं बदला।

इसे नाम देकर कहना इसलिए ज़रूरी है क्योंकि इसे बनाने का फ़ैसला कभी लिया ही नहीं जाता। यह अपने आप जमा होता जाता है। कौन-से हिस्से आप ख़ुद संभालना चाहते हैं और कौन-से नहीं, यह शुरू में ही तय कर लेना नौवें महीने में जवाब पता चलने से सस्ता पड़ता है।

इसे वहीं चलाइए जहाँ कोड बदलता है

रिलीज़ से पहले चलने वाली Python suite चीज़ें देर से पकड़ती है। असली फ़र्क़ हर pull request पर चलाने से पड़ता है।

दो रास्ते हैं, और चुनाव असल में इस बात का है कि पाइपलाइन किसके ज़िम्मे है। डैशबोर्ड से GitHub App को कनेक्ट करने पर आपकी रिपॉज़िटरी में ज़रा भी बदलाव नहीं करना पड़ता, क्योंकि यह उसी डिप्लॉयमेंट पर प्रतिक्रिया देता है जो आपका बिल्ड पहले से भेजता है। एक GitHub Actions स्टेप जोड़ने पर यह जाँच रिपो के भीतर आ जाती है, जहाँ बाक़ी बिल्ड की तरह इसका भी रिव्यू होता है।

TestSprite क्या संभालता है, ताकि आपको न संभालना पड़े

जो चार चीज़ें एक pytest suite को इन्फ्रास्ट्रक्चर में बदल देती हैं, उन्हें यहाँ प्रोडक्ट की तरह संभाला जाता है। Auto-Authentication हर एनवायरनमेंट के लिए sessions हासिल करता है और उन्हें रिफ़्रेश करता है। Dynamic Variables एक रिस्पॉन्स से मिला identifier अगली रिक्वेस्ट तक पहुँचाते हैं। Dependency Chains यह देखकर एक्ज़िक्यूशन का क्रम तय करती हैं कि हर केस को क्या चाहिए और वह क्या पैदा करता है, इसलिए कोई विफलता अपने आश्रित केसों को फेल करने के बजाय उन्हें छोड़ देती है। Auto-Cleanup ठीक वही हटाता है जो किसी रन ने बनाया था, और यही समानांतर एक्ज़िक्यूशन को सुरक्षित बनाता है।

कवरेज भी एक अलग दिशा से आती है। API Discovery उन endpoints की गिनती करता है जो चल रही सर्विस असल में एक्सपोज़ करती है, और जेनरेट किए गए प्लान उन error paths और boundary values को शामिल करते हैं जो स्प्रिंट के आख़िर में कभी नहीं लिखे जाते।

आपको मिलती है एक ऐसी suite जिसे बदलने से कोई नहीं डरता, और कोई ऐसा conftest नहीं होता जिसे सिर्फ़ एक व्यक्ति समझता हो। यूनिट और लॉजिक टेस्ट के लिए pytest बनाए रखिए, जहाँ वह सचमुच सबसे अच्छा टूल है; बात सिर्फ़ इतनी है कि कवरेज की चौड़ाई कहाँ रहे।