Vibe Testing: चेक लिखने के बजाय उन्हें शब्दों में बताना

Vibe testing असल में क्या हटाता है

यह अनुवाद वाला कदम हटा देता है। आम तौर पर आपको पता होता है कि आपको कौन-सा व्यवहार चाहिए, फिर आप एक घंटा उसे सेलेक्टर, वेट और असर्शन में बदलने में लगाते हैं — और उसका ज़्यादातर हिस्सा आपके प्रोडक्ट के बारे में नहीं, फ़्रेमवर्क के बारे में होता है। व्यवहार को शब्दों में बताकर अनुवाद का काम एजेंट पर छोड़ देने से वह हिस्सा बचा रहता है जिसमें अर्थ है, और वह छूट जाता है जिसमें नहीं।

दूसरी चीज़ जो यह हटाता है, वह है मेंटेनेंस का बोझ। इरादे के रूप में लिखा गया स्टेप ऐसे रीडिज़ाइन से बच जाता है जिसमें हार्डकोडेड सेलेक्टर टूट जाता है, क्योंकि बटन की जगह बदलने के बाद भी इरादा उतना ही सच रहता है।

शब्दों में बताया गया चेक कहाँ गलत होता है

वह एक आदत जो असली चेक को दिखावटी चेक से अलग करती है

जानबूझकर चीज़ को तोड़ें और पुष्टि करें कि चेक लाल हो जाता है। इसमें एक मिनट लगता है, और यही अकेला सबूत है कि चेक किसी चीज़ से जुड़ा हुआ है।

हाथ से लिखे टेस्ट के मुकाबले यहाँ इसकी अहमियत और ज़्यादा है, क्योंकि शब्दों में बताए गए चेक में उदार व्याख्या की गुंजाइश ज़्यादा होती है। ऐसा रन जो बिना किसी असर्शन तक पहुँचे पूरा हो जाए, पास नहीं कहलाता — और यह पता लगाने का एकमात्र तरीका यही है कि आप उसे फ़ेल कराने की कोशिश करें।

शुरुआत कैसे करें

सेटअप इस क्षमता को कोडिंग एजेंट में इंस्टॉल कर देता है, ताकि चेक वहीं बताए और चलाए जा सकें जहाँ कोड लिखा जा रहा है।

इसके लिए टर्मिनल की ज़रूरत नहीं है। TestSprite डैशबोर्ड में एक प्रोजेक्ट बनाएँ, चेक को सादी भाषा में बताएँ, और उसे अपने ऐप पर लगा दें। आपकी टीम के डेवलपर चाहें तो यही काम कमांड लाइन से भी कर सकते हैं; इसके लिए देखें CLI रिपॉज़िटरी।

सबसे पहले क्या बताएँ

• वह फ़्लो जिसे आप डेमो में दिखाएँगे। यह टूटा तो सबके सामने पता चलेगा, इसलिए सबसे पहले इसी को कवर करना चाहिए।

• पैसे या परमिशन से जुड़ी हर चीज़। गलत होने पर नुकसान सबसे ज़्यादा, और दोनों चुपचाप फ़ेल होते हैं।

• सबसे हाल में जो चीज़ टूटी थी। जिस चीज़ ने एक बार आपको फँसाया, वह हमेशा के लिए एक चेक की हकदार है — और आपको पहले से ठीक-ठीक पता है कि उसे कैसे बताना है।

ऐसा चेक बताना जो टिका रहे

जो चेक आपकी हिफ़ाज़त करता है और जो सिर्फ़ पाइपलाइन की शोभा बढ़ाता है, उनके बीच फ़र्क़ लगभग हमेशा इसी बात में होता है कि उसे कैसे बताया गया था — और यह तरीका सीखा जा सकता है।

अच्छे वर्णन के तीन हिस्से होते हैं: एक शुरुआती स्टेट, एक एक्शन, और उसके बाद कुछ ऐसा जो दिखाई दे और जिसकी पुष्टि रीलोड करने पर हो जाए। "साइन-इन किए हुए ऐसे यूज़र के तौर पर जिसका कोई सेव किया हुआ फ़िल्टर नहीं है, Recent नाम का फ़िल्टर बनाएँ, रीलोड करें, और पुष्टि करें कि वह साइडबार में दिखता है।" इसका हर हिस्सा फ़ेल हो सकता है, और फ़ेल होने पर पता चलता है कि कहाँ।

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

फिर यह तय करना बंद करें कि उन्हें कब चलाना है

शब्दों में बताया गया हो या कोड में लिखा, जो चेक किसी इंसान का इंतज़ार करता है वह व्यस्त हफ़्ते में छूट ही जाता है।

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

शब्दों में बताए गए चेक के साथ TestSprite क्या करता है

आप बताते हैं कि क्या सच होना चाहिए; TestSprite यह तय करता है कि उसे कैसे जाँचा जाए और उसे आपके डिप्लॉय किए गए ऐप पर चलाता है। अनुवाद वाला वह कदम, जो कभी मक़सद था ही नहीं, गायब हो जाता है।

दो खूबियाँ नतीजे को टिकाऊ बनाती हैं। स्टेप्स DOM के रास्तों के रूप में नहीं, बल्कि इरादों के रूप में सहेजे जाते हैं, इसलिए ऐसा रीडिज़ाइन जिसमें बटन की जगह बदल जाए, चेक को नहीं तोड़ता। और नतीजा इस रूप में आता है कि क्या करने की कोशिश की गई, क्या हुआ, और दोनों कहाँ अलग हो गए — यही चीज़ किसी कोडिंग एजेंट को फ़ेल्योर पर काम करने देती है, बिना इसके कि पहले कोई इंसान उसकी व्याख्या करे।

सुधार भी सादी भाषा में ही होता है। अगर कोई चेक बहुत ढीला है, तो कोड एडिट करने के बजाय एक वाक्य में यह कह दीजिए — और यही पूरी वजह है कि शब्दों में बताए गए चेक रखने लायक हैं।