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