डिबगिंग टूल्स और वह स्टेप जो ज़्यादातर सेटअप में मौजूद नहीं होता

श्रेणी के अनुसार डिबगिंग टूल्स, और हर एक किस बात को पहले से मान लेता है

इनमें से हर एक यह मान लेता है कि आप फेलियर तक पहुँच चुके हैं। असली घंटे उसी मान्यता में खर्च होते हैं।

जो स्टेप छूट जाता है

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

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

कोडिंग एजेंट के साथ यह ज़्यादा क्यों मायने रखता है

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

चीज़ों को आज़माने का क्रम

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

क्या यह पूरी तरह साफ़ स्टेट से भी होता है। अगर नहीं, तो यह पहले से बची हुई स्टेट है और कोड में वैसी कोई गड़बड़ी नहीं है जैसी आप सोच रहे हैं।

क्या यह किसी दूसरे एनवायरनमेंट में भी होता है। अगर नहीं, तो बग एनवायरनमेंट्स के बीच का फ़र्क़ ही है, और आप डिफ़ पढ़ना बंद कर सकते हैं।

क्या यह हर बार होता है। अगर नहीं, तो मामला टाइमिंग या कनकरेंसी का है, जिससे वे लगभग सभी डिटरमिनिस्टिक वजहें ख़ारिज हो जाती हैं जिन्हें आप जाँचने वाले थे।

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

फ़िक्स के बाद रिप्रोडक्शन को सहेज कर रखें

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

अगर आप लोकल मशीन पर कुछ इंस्टॉल नहीं करना चाहते, तो यही सेटअप TestSprite डैशबोर्ड में भी उपलब्ध है। बाकी पूरा CLI हिस्सा यहाँ मौजूद है — CLI रिपॉज़िटरी।

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

• GitHub Actions यह स्टेप आपके ख़ुद के वर्कफ़्लो के अंदर रखता है, जिसे टर्मिनल से कॉन्फ़िगर किया जाता है।

TestSprite यह छूटा हुआ स्टेप कैसे देता है

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

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

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