Vibe testing MCP सेटअप किस चीज़ को हटा देता है
ज़्यादातर context switch को। आम तौर पर जाँच करने का मतलब है बातचीत छोड़ना, ऐप खोलना, क्लिक करते हुए आगे बढ़ना, कुछ नोटिस करना, और फिर लौटकर उसे बयान करना। इनमें से हर कदम पर थोड़ी जानकारी खो जाती है, और सबसे ज़्यादा आख़िरी कदम पर।
कनेक्शन जुड़ जाने के बाद क्लिक agent करता है और जो हुआ उसे आपकी याददाश्त के बजाय एक रिकॉर्ड के रूप में दर्ज करता है। आप एक ही जगह बने रहते हैं और सबूत बेहतर हो जाता है।
आप क्या माँगते हैं, और बदले में क्या मिलता है
काम की माँग किसी ठोस चीज़ का नाम लेती है, जिसकी पुष्टि पेज reload करने पर हो सके। "देख लो कि sign up काम करता है" इतना ढीला है कि कभी फेल ही नहीं हो सकता। "नए ईमेल से sign up करो, sign out करो, फिर वापस sign in करो, और पुष्टि करो कि dashboard पर नया अकाउंट दिख रहा है" — यह एक जाँच है।
जो जवाब आए उसमें यह होना चाहिए कि क्या करने की कोशिश की गई, ऐप ने क्या किया, और दोनों कहाँ जाकर अलग हो गए। आख़िरी हिस्सा ही किसी failure को महज़ हतोत्साहित करने वाली ख़बर के बजाय काम लायक बनाता है।
तीन जाल, जिनके बारे में जानना ज़रूरी है
| ऐसी जाँचें जो फेल हो ही नहीं सकतीं | अस्पष्ट माँगों से ऐसी जाँचें बनती हैं जो हमेशा pass होती हैं — भरोसा दिलाती हैं, बचाती कुछ नहीं। |
| ग़लत रास्ते से आया हरा निशान | जिस agent से कहा जाए कि जाँच pass कराओ, वह जाँच को ही बदल सकता है। उसने जो बनाया है, उसे एक बार पढ़ लें। |
| कल को भूल जाना | बातचीत उसी चीज़ की जाँच करती है जिस पर आप अभी काम कर रहे हैं। पुराने फ़ीचर्स के लिए ऐसी जाँचें चाहिए जो session के बाद भी बनी रहें। |
इसे सेट अप करना
MCP server, CLI से अलग एक पैकेज है और इसका प्रकाशित नाम है @testsprite/testsprite-mcp। इसे dashboard से मिली API key के साथ अपने editor की MCP settings में जोड़ें, और editor उसे एक subprocess की तरह चलाता है। Claude Code, Cursor, Windsurf, VS Code, GitHub Copilot और Trae — सभी इसे सपोर्ट करते हैं; सटीक configuration हर client में अलग होती है और उसका विवरण यहाँ है: MCP installation documentation।
वह आदत जो इसे असली बनाती है
जब agent बताए कि कोई जाँच pass हो गई है, तो उस चीज़ को जानबूझकर तोड़ें और पक्का करें कि जाँच लाल होती है। एक मिनट लगता है, और यही इकलौता सबूत है कि जाँच का आपके ऐप से कोई नाता है भी या नहीं।
तीन काम की माँगें, और उनके कमज़ोर रूप
काम की जाँच और सजावटी जाँच का फ़र्क़ उसी माँग में दिख जाता है जिससे वह बनी थी।
कमज़ोर: "देखो dashboard लोड होता है।" बेहतर: "sign in करो, dashboard खोलो, और पुष्टि करो कि revenue tile में डैश की जगह कोई संख्या दिख रही है।" दूसरी वाली फेल हो सकती है।
कमज़ोर: "पक्का करो कि सेव होना काम करता है।" बेहतर: "project का नाम बदलकर Alpha करो, पेज reload करो, और पुष्टि करो कि header में Alpha लिखा है।" reload ही वह चीज़ है जो स्क्रीन पर दिखे बदलाव को सचमुच सेव हुए बदलाव से अलग करती है।
कमज़ोर: "permissions टेस्ट करो।" बेहतर: "दूसरे अकाउंट से पहले अकाउंट के project का लिंक खोलो और पुष्टि करो कि पहुँच नहीं मिलती।" दूसरे अकाउंट का नाम लेना ही एक अमूर्त चिंता को ऐसी चीज़ में बदल देता है जिसका कोई नतीजा निकलता है।
हर जोड़ी में काम वाला रूप टाइप करने में करीब दस सेकंड ज़्यादा लेता है, और वही इकलौता रूप है जो कभी आपको ऐसा कुछ बताएगा जो आपने पहले से मान नहीं रखा था।
फिर इन्हें अपने बिना चलने दें
तंत्र से ज़्यादा मायने trigger रखता है। इसे अपने deployment event से जोड़ देने का मतलब है कि हर बदलाव की जाँच बिना किसी के तय किए हो जाती है; यह काम GitHub App dashboard से करता है, और एक GitHub Actions step इसे आपके workflow के भीतर से करता है। ब्यौरा यहाँ है: CLI repository।
इस कनेक्शन से आपको क्या मिलता है
आप उसी बातचीत में जाँच का ब्यौरा देते हैं जिसमें आप पहले से हैं, और TestSprite उसे आपके deployed ऐप पर चलाकर बताता है कि क्या हुआ। न terminal, न test file, न editor छोड़ना।
दो बातें इसे महज़ सुविधाजनक नहीं, बल्कि सचमुच रखने लायक बनाती हैं। सबूत आपकी याददाश्त नहीं, एक रिकॉर्ड होता है, इसलिए दोबारा बताने में कुछ खोता नहीं। और जाँचें बनी रहती हैं, इसलिए जिस flow की पुष्टि आपने आज की है, अगले हफ़्ते के बदलावों के बाद भी उसकी पुष्टि होती रहती है।
सब कुछ TestSprite dashboard में भी मौजूद है, और अगर आपका काम chat विंडो में नहीं होता तो यही बेहतर रास्ता है।
क्या मुझे terminal इस्तेमाल करना पड़ेगा?
नहीं। कनेक्शन editor या chat के भीतर ही काम करता है, और सब कुछ TestSprite dashboard में भी मौजूद है।
अगर मैंने जाँच का ब्यौरा ठीक से न दिया तो?
आपको ऐसी जाँच मिलेगी जो pass तो होती है पर उसका कोई मतलब नहीं। किसी ठोस, दिखने वाली चीज़ का नाम लेना और यह पक्का करना कि जाँच फेल भी हो सकती है — इससे लगभग पूरी समस्या ठीक हो जाती है।
क्या यह login के पीछे की चीज़ों की जाँच कर सकता है?
हाँ, बशर्ते उस environment के लिए credentials कॉन्फ़िगर हों। इन्हें जाँच के विवरण में नहीं, environment में ही रखें।
यह agent से टेस्ट लिखवाने से कैसे अलग है?
लिखे हुए टेस्ट को भी चलाने के लिए कोई जगह और चलाने वाला कोई चाहिए होता है। यह deployed ऐप पर चलता है और सबूत लौटाता है, और यही वह हिस्सा है जो चक्र को पूरा करता है।
क्या हर जाँच पर कुछ खर्च होता है?
हर run में credits खर्च होते हैं। किसी लंबे session पर agent लगाने से पहले यह जान लेना ठीक रहेगा, क्योंकि जिस agent के पास जाँचने का औज़ार होगा, वह उसे इस्तेमाल करेगा ही।
कुछ ठोस माँगें, फिर उसे एक बार फेल कराकर देखें।
Vibe testing MCP कनेक्शन आपको उसी बातचीत में अपने ऐप की जाँच करने देता है जिसमें आप उसे बनाते हैं। किसी ठोस, दिखने वाली चीज़ का नाम लें, agent ने जो बनाया है उसे पढ़ें, पक्का करें कि वह लाल हो सकती है, और एक pipeline trigger जोड़ें ताकि पुराने फ़ीचर्स भी कवर बने रहें।