कोड पढ़ने से बेहतर क्यों है Web App Testing MCP कनेक्शन
किसी वेब ऐप्लिकेशन को स्थिर रूप से पढ़ने पर यह पता चलता है कि कोड करना क्या चाहता है। यह नहीं पता चलता कि ब्राउज़र उसके साथ करता क्या है। इन दोनों के बीच का फ़ासला ही वह जगह है जहाँ यूज़र को दिखने वाली ज़्यादातर ख़ामियाँ रहती हैं, और जैसे-जैसे कोड का बड़ा हिस्सा ऐसे एजेंट से आने लगता है जिसने ऐप को कभी render होते देखा ही नहीं, यह फ़ासला और चौड़ा होता जाता है।
रिव्यू में जो नहीं पकड़ा जाता, वह यहाँ पकड़ा जाता है
बची रह जाने वाली state
कोई modal scroll lock छोड़ जाता है, कोई फ़िल्टर ऐसे context में भी टिका रहता है जहाँ उसका कोई मतलब नहीं।
सिर्फ़ दूसरी बार इस्तेमाल करने पर दिखता है, diff में कभी नहीं।
डेटा से पहले render
पेज पेंट हो जाता है, fetch पूरा हो जाता है, और कुछ भी दोबारा render नहीं होता।
ऐप को इस्तेमाल करके इसे भरोसे के साथ दोहराया जा सकता है, वरना यह लगभग अदृश्य रहता है।
दूसरा अकाउंट
ownership और visibility को लेकर ऐसी धारणाएँ जो डेवलपर के अपने सेशन में सही बैठती हैं, किसी और के सेशन में नहीं।
लोकल डेवलपमेंट
वेब ऐप का काम कुछ भी deploy होने से बहुत पहले localhost पर होता है, और जो जाँच सिर्फ़ किसी पब्लिक URL तक पहुँचती है, वह इतनी देर से आती है कि आप जो बना रहे हैं उसे बदल नहीं पाती। लोकल टारगेट सपोर्ट किए जाते हैं, इसलिए जाँच तब उपलब्ध रहती है जब आप काम कर ही रहे होते हैं, न कि सिर्फ़ deploy के बाद। मौजूदा तरीक़ा दिया गया है डॉक्यूमेंटेशन में।
इसे सेट अप करना
MCP सर्वर, CLI से अलग एक पैकेज है, जिसका नाम है @testsprite/testsprite-mcp। इसे डैशबोर्ड से मिली API key के साथ अपने एडिटर की MCP सेटिंग्स में जोड़ें, और एडिटर उसे एक subprocess के रूप में चलाता है। Claude Code, Cursor, Windsurf, VS Code, GitHub Copilot और Trae — ये सभी इसे सपोर्ट करते हैं; सटीक कॉन्फ़िगरेशन हर क्लाइंट के लिए अलग है और वह दिया गया है MCP इंस्टॉलेशन डॉक्यूमेंटेशन में।
सबसे पहले क्या कवर करें
साइन अप, साइन आउट, साइन इन। जेनरेट किए गए वेब ऐप में सबसे आम पूर्ण विफलता।
कुछ बनाएँ और रीलोड करें। इससे "स्क्रीन अपडेट हो गई" और "रिकॉर्ड मौजूद है" का फ़र्क़ अलग हो जाता है।
किसी दूसरे अकाउंट से मुख्य फ़्लो। डेवलपर के अपने सेशन में बैठी हुई permission संबंधी धारणाओं को पकड़ता है।
तीन state वाला जाल
वेब ऐप की एक ख़ास बात यह है कि एक ही फ़ीचर एक साथ तीन आपस में मेल न खाने वाली states में हो सकता है, और ज़्यादातर runtime बग इन्हीं के बीच का टकराव होते हैं।
सर्वर के पास एक रिकॉर्ड है। ब्राउज़र के पास मेमोरी में उसकी एक कॉपी है। और यूज़र के मन में वह तस्वीर है जो उसने कुछ पल पहले देखी थी। ऐसा delete जो रिकॉर्ड और मेमोरी वाली कॉपी तो हटा दे लेकिन स्क्रीन पर पंक्ति छोड़ जाए, यूज़र को यह यक़ीन दिला देता है कि delete फ़ेल हो गया। और ऐसा save जो स्क्रीन अपडेट कर दे पर सर्वर नहीं, इसका ठीक उल्टा नतीजा देता है।
इसका व्यावहारिक नतीजा यह है कि जो जाँच इन तीनों में से सिर्फ़ एक को देखती है, वह बहुत कम साबित करती है। किसी क्रिया के तुरंत बाद स्क्रीन पर assert करना ब्राउज़र वाली कॉपी को जाँचता है। रीलोड के बाद assert करना सर्वर को जाँचता है। वही क्रिया दो बार करना यह जाँचता है कि पहली बार कुछ पीछे छूटा तो नहीं। ये तीनों मिलकर उस ज़्यादातर हिस्से को कवर कर लेते हैं जो सचमुच यूज़र तक पहुँचता है, और इनमें से किसी के लिए भी कोड पढ़ने की ज़रूरत नहीं।
फिर इसे सेशन के बाद भी चलता रखें
MCP कनेक्शन बदलाव के उसी पल को कवर करता है। रिग्रेशन के लिए ज़रूरी है कि वही जाँचें चलती रहें, चाहे कोई कीबोर्ड पर बैठा हो या नहीं।
GitHub App एक webhook है जिसे आप TestSprite डैशबोर्ड में सेट अप करते हैं। यह उसी deployment इवेंट को सुनता है जो आपकी pipeline पहले से पैदा करती है, इसलिए आपकी रिपॉज़िटरी में कुछ भी नहीं बदलता।
GitHub Actions इस स्टेप को आपके अपने workflow के भीतर रखता है, जिसे टर्मिनल से कॉन्फ़िगर किया जाता है। मौजूदा कमांड दिए गए हैं CLI रिपॉज़िटरी में।
TestSprite वह क्या जाँचता है जो कोई diff नहीं जाँच सकता
यह चल रहे ऐप्लिकेशन को खोलकर उसे इस्तेमाल करता है, और ऊपर बताई तीनों ख़राबियाँ देखने का यही एकमात्र तरीक़ा है। किसी इंटरैक्शन के बाद पीछे छूटी state, ऐसा render जो अपने डेटा तक कभी पहुँच ही नहीं पाता, और दूसरे अकाउंट के लिए अलग व्यवहार — ये सब सोर्स में अदृश्य रहते हैं और इस्तेमाल में साफ़ दिखते हैं।
चूँकि यह कनेक्शन एजेंट के लूप के भीतर ही बैठा होता है, इसलिए जाँच बदलाव के बाद नहीं, बल्कि बदलाव करने की प्रक्रिया के हिस्से के रूप में होती है। एजेंट केस बनाता है, उसे चलाता है, फ़र्क़ पढ़ता है और दोहराता है — और आपको पूरा चक्कर नहीं, सिर्फ़ नतीजा दिखता है।
आख़िर में आपके पास फ़्लो का एक ऐसा सेट रह जाता है जिसे हर बदलाव पर दोबारा जाँचा जाता है, ताकि permission वाली वह धारणा या वह बासी फ़िल्टर, जिस सेशन ने उन्हें पकड़ा था उसके ख़त्म होने के बाद चुपचाप वापस न आ सकें।
क्या इसे मेरे सोर्स कोड की ज़रूरत है?
नहीं। यह चल रहे ऐप्लिकेशन को उसके इंटरफ़ेस के ज़रिए चलाता है और व्यवहार की रिपोर्ट देता है। कोड तो आपके एजेंट के पास पहले से है।
क्या यह लोकल dev सर्वर को टेस्ट कर सकता है?
फ़्रंटएंड रन के लिए हाँ, आपकी मशीन से एक tunnel के ज़रिए। सिर्फ़ बैकएंड वाले लोकल टारगेट के लिए अब भी एक पहुँच योग्य URL चाहिए।
उन फ़्लो का क्या जिनमें असली ईमेल या पेमेंट चाहिए?
टेस्ट मोड और अलग से बनाए गए अकाउंट इस्तेमाल करें। जिसमें किसी असली थर्ड-पार्टी साइड इफ़ेक्ट की ज़रूरत हो, उसे सोच-समझकर मैन्युअल जाँच के तौर पर करना बेहतर है।
एक वेब ऐप में कितनी जाँचें होनी चाहिए?
ऊपर बताई तीन से शुरू करें, फिर जो बग आपको सचमुच झेलने पड़ें, हर एक के लिए एक जोड़ते जाएँ। असली ख़राबियों के पीछे चलने वाली कवरेज, किसी प्रतिशत को निशाना बनाकर बनाई गई कवरेज से बेहतर होती है।
क्या यह CLI जैसा ही है?
क्षमता वही है, दाख़िल होने का रास्ता अलग है। MCP एडिटर के भीतर के काम के लिए ठीक बैठता है, CLI स्क्रिप्ट और pipelines के लिए।
ऐप को खोलिए, सिर्फ़ पढ़िए मत।
Web App Testing MCP कनेक्शन एजेंट को पीछे छूटी state, डेटा से पहले render और दूसरे अकाउंट वाली वे दिक़्क़तें ढूँढ़ने देता है जो किसी diff में नहीं दिखतीं। पहले साइन-इन, डेटा के टिके रहने और दूसरे अकाउंट को कवर करें, फिर सेशन ख़त्म होने के बाद भी जाँचें चलती रहने दें।