Cursor bug आम bug क्यों नहीं है
वही बदलाव लिखने वाला इंसान अपने साथ वह context लेकर चलता है जो editor कभी नहीं देखता। उसे याद रहता है कि settings panel एक cache से पढ़ता है जिसे invalidate करना ज़रूरी है, कि जब तक कोई file चुनी न जाए तब तक upload button disabled रहता है, कि कोई endpoint मेल न मिलने पर 404 नहीं बल्कि खाली array लौटाता है। Cursor सिर्फ़ उन files और उस text से काम करता है जो आपने खोली और लिखी हैं। उस खिड़की के बाहर की हर चीज़ अनुमान है।
इसलिए यहाँ खराबी गलत syntax की नहीं है। यह ऐसा बदलाव है जो स्थानीय स्तर पर सही और पूरे सिस्टम के स्तर पर गलत है। function ठीक वही करता है जो वह कहता है। बस उसे गलत समय पर call किया जाता है, या वह state का कोई टुकड़ा पीछे छोड़ देता है, या वह ऐसे ढाँचे को मान लेता है जो API ने दो sprint पहले लौटाना बंद कर दिया था।
unit tests इसे नहीं पकड़ते, क्योंकि unit tests उन्हीं मान्यताओं पर लिखे जाते हैं जिन पर code लिखा गया था। अगर दोनों agent ने ही लिखे हैं, तो वे आपस में सहमत रहते हैं और आपके product से असहमत।
Cursor bugs असल में कहाँ से आते हैं
ज़्यादातर मामले तीन जगहों से आते हैं।
Interface state
form submit हो जाता है, पर उसके पीछे की list refresh नहीं होती।
modal बंद हो जाता है और body पर scroll lock छोड़ जाता है।
request पहले से चल रही होती है फिर भी button enabled रहता है, इसलिए दो बार click करने पर दो records बन जाते हैं।
Asynchronous flows
data आने से पहले ही screen render हो जाती है और फिर दोबारा कभी render नहीं होती।
कोई background job शुरू तो होता है, पर उसका इंतज़ार कोई नहीं करता, इसलिए अगला step पुराने values पढ़ लेता है।
error वाला रास्ता चुपचाप resolve हो जाता है और जो काम नाकाम रहा, उस पर user को success message दिखता है।
Integration boundaries
payload, type definition से तो मेल खाता है, पर उससे नहीं जो service असल में स्वीकार करती है।
मान लिया जाता है कि authentication मौजूद है, क्योंकि agent ने जो session देखा था उसमें वह मौजूद था।
pagination, empty states और rate limits को type system में सँभाल लिया जाता है, और कहीं नहीं।
इन सबमें एक बात समान है: इन्हें आप तभी देख सकते हैं जब application को चलाकर इस्तेमाल करें। diff पढ़ने से इनमें से कोई सामने नहीं आएगा, और न ही ऐसे test suite से जो कभी browser खोलता ही नहीं।
merge होने से पहले Cursor bugs कैसे पकड़ें
जाँच deployed app पर होनी चाहिए, उसी तरह चलाई जाए जैसे कोई इंसान चलाता, और नतीजा ऐसे रूप में वापस आना चाहिए जिस पर agent काम कर सके। वरना bug तो मिल गया, लेकिन ठीक फिर भी आपको ही करना है।
तीन बातें सच होनी चाहिए। इनमें से कोई मुश्किल नहीं है; इनमें से एक भी छूट जाए तो loop लीक करने लगता है।
agent को पता होना चाहिए कि जाँच कैसे करनी है
Setup एक verification skill सीधे coding agent में ही install कर देता है, ताकि वह README से अंदाज़ा लगाने के बजाय जान सके कि tests कैसे बनाने, चलाने और छाँटने हैं। यह instruction file वहीं लिखता है जहाँ आपका editor पहले से ऐसी file ढूँढ़ता है, यानी Cursor इसे सीधे यहाँ से उठा लेता है: .cursor/rules/ ठीक वैसे ही जैसे Claude Code अपनी skill directory पढ़ता है। आठ editors समर्थित हैं, जो उस टीम में मायने रखता है जहाँ सब एक ही editor इस्तेमाल नहीं करते।
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
अगर आप स्थानीय तौर पर कुछ भी install नहीं करना चाहते, तो यही काम TestSprite dashboard से भी हो सकता है। CLI और जो कुछ भी कर सकता है, वह सब यहाँ है — CLI repository।
जाँच mock पर नहीं, deployed app पर होनी चाहिए
run को उस environment की तरफ़ मोड़िए जहाँ बदलाव live है। agent application खोलता है, किसी user की तरह उस behavior से गुज़रता है, और बताता है कि असल में हुआ क्या — न कि यह कि sandbox में कोई assertion पूरी हुई या नहीं। mocks यह संकेत दे ही नहीं सकते, इसीलिए हरा unit suite और टूटा हुआ feature इतने आराम से साथ-साथ रह लेते हैं।
नाकामी ऐसे रूप में लौटनी चाहिए जिसे agent इस्तेमाल कर सके
यही हिस्सा तय करता है कि loop बंद होता है या नहीं। अगर नाकामी dashboard में एक screenshot की शक्ल में आती है, तो किसी इंसान को उसे पढ़ना, समझना और फिर prompt लिखना पड़ेगा। लेकिन अगर वह एक ही सुसंगत बंडल के रूप में आए — क्या करने की कोशिश हुई, app ने क्या किया, और कहाँ जाकर दोनों अलग हुए — तो agent उसे उठाकर सीधे उस पर काम कर सकता है। अगला दोहराव आपके दिए विवरण से नहीं, सबूत से शुरू होता है।
इसे ऐसा बनाइए कि किसी को याद रखना ही न पड़े
जिस जाँच को आप हाथ से चलाते हैं, वही जल्दबाज़ी वाले दिन छूट जाती है — और ज़रूरत उसी दिन होती है। इसे अपने आप चलाने के दो तरीके हैं, और कौन-सा आपके लिए ठीक है यह इस पर निर्भर करता है कि आपकी pipeline किसके ज़िम्मे है।
GitHub App एक webhook है जिसे आप TestSprite dashboard में सेट करते हैं। यह उसी deployment event को सुनता है जो आपकी pipeline पहले से पैदा करती है, इसलिए आपकी repository में कुछ नहीं बदलता।
GitHub Actions इस step को आपके अपने workflow के भीतर रखता है, जिसे terminal से configure किया जाता है।
यह मॉडल समझने लायक है, भले ही आप configuration को कभी हाथ न लगाएँ। यह integration आपकी application को न build करता है, न deploy, और न ही workflow files जोड़ता या बदलता है। यह उसी deployment event को सुनता है जो आपकी pipeline पहले से पैदा करती है, और "नया build इस URL पर live है" को run शुरू करने का संकेत मानता है। नतीजे वहीं वापस आते हैं जहाँ काम हो रहा है — pull request पर comment के रूप में, या commit पर check के रूप में।
दो फ़ैसले तय करते हैं कि यह उपयोगी रहेगा या नहीं, और दोनों configuration का नहीं, समझदारी का मामला हैं।
कौन-सा पल "तैयार" माना जाए। वह event चुनिए जो deployment के live होने के बाद चलता है, वह नहीं जो build शुरू होते ही चल जाता है। बहुत जल्दी आने वाला event run को ऐसे URL की तरफ़ भेज देता है जो अभी उठा ही नहीं है, और तब हर test ऐसी वजह से fail होता है जिसका आपके code से कोई लेना-देना नहीं। setup के बिगड़ने की सबसे आम वजह यही एक है।
जाँच सलाह भर है या बाध्यकारी। pull request पर comment सिर्फ़ जानकारी देता है। required check merge रोक देता है। एक हफ़्ते इसे सलाह वाले मोड में चलाकर देखिए कि यह क्या-क्या पकड़ती है, फिर फ़ैसला कीजिए। पहले ही दिन इसे बाध्यकारी बना देना, जब तक किसी का उस पर भरोसा न बना हो, एक काम की जाँच को बंद करवाने का तरीका है।
अगर आपके previews Vercel या Netlify जैसे platform पर रहते हैं तो एक व्यावहारिक बात: हर host preview URL अलग तरीके से नाम देता है, इसलिए integration एक तय पते के बजाय एक pattern लेता है और हर run में branch या pull request भर देता है।
यह आपके मौजूदा tests के साथ कहाँ बैठता है
यह चलते हुए product पर behavior की जाँच है, इसलिए यह तेज़ local unit tests की जगह नहीं लेती, बल्कि उनका पूरक है। logic के लिए unit tests रखिए, और इससे वह हिस्सा ढँकिए जो वे अपनी बनावट के कारण देख ही नहीं सकते: कि असली user के चलाने पर feature काम करता है या नहीं।
एक बड़े पैटर्न पर एक बात
इसमें से कुछ भी सिर्फ़ Cursor तक सीमित नहीं है। यही खाई हर उस assistant के साथ बनती है जो इंसान के पढ़ने की रफ़्तार से तेज़ code लिखता है, इसीलिए verification वाले कदम को एक बार बनाकर सभी editors में दोबारा इस्तेमाल करना फ़ायदेमंद है। एक खुले leaderboard पर, जहाँ agents ने एक ही application बनाई, इस verification loop के रहते मैदान के सबसे सस्ते model ने सबसे सही app भेजी — और सबसे महँगी entry की आधी लागत में। सबक यह नहीं था कि कोई एक model बेहतर है। सबक यह था कि काम करने वाले feedback संकेत वाला model, बिना संकेत वाले ज़्यादा ताक़तवर model से आगे निकल जाता है।
TestSprite इस Cursor loop में कहाँ फ़िट होता है
TestSprite verification वाला आधा हिस्सा है। Cursor बदलाव लिखता है; TestSprite deployed app खोलता है, user की तरह उस behavior से गुज़रता है, और बताता है कि असल में हुआ क्या। दोनों में से कोई दूसरे का काम करने की कोशिश नहीं कर रहा, और यही अलगाव असली बात है: किसी बदलाव की पुष्टि के लिए उसका लेखक ही सबसे गलत पक्ष है।
Cursor से लिखा code भेजने वाली टीम के लिए इससे तीन चीज़ें निकलती हैं। coverage अब इस पर निर्भर नहीं रहती कि tests लिखने का समय किसे मिलता है, क्योंकि cases आपके product से बनते हैं और सीधी-सादी भाषा में सुधारे जाते हैं। ऊपरी redesign से suite लाल होना बंद हो जाता है, क्योंकि यहाँ हर step DOM का कोई रास्ता नहीं, एक इरादा है। और नाकामी एक ऐसे बंडल के रूप में लौटती है जिस पर agent काम कर सके, इसलिए अगला दोहराव आपके विवरण से नहीं, सबूत से शुरू होता है।
पहले दिन आपको इतना मिलना चाहिए: वे flows जिनका टूटना आपको शर्मिंदा करे, हर pull request पर चलते हुए, और ऐसा नतीजा जो बताए कि फ़र्क कहाँ पड़ा। यह आपके code की समीक्षा नहीं करता और तेज़ local unit tests की जगह नहीं लेता; यह दोनों के साथ मिलकर चलता है।
feature टूटा होने पर भी Cursor के अपने tests pass क्यों हो जाते हैं?
क्योंकि tests और code, दोनों एक ही मान्यताओं से निकले हैं। अगर agent ने मान लिया कि कोई endpoint खाली array लौटाता है और उसी भरोसे handler और test दोनों लिख दिए, तो वे आपस में सहमत ही रहेंगे। यह गाँठ सिर्फ़ असली application को असली service के सामने चलाकर ही खुलती है।
इसे सेट करने के लिए क्या मुझे QA टीम चाहिए?
नहीं। setup में बस एक CLI command और एक GitHub App install है। यह उन टीमों के लिए बना है जहाँ test का नतीजा देखने वाले सिर्फ़ developers ही होते हैं।
क्या इसे मेरे source code तक पहुँच चाहिए?
जाँच आपकी deployed application पर, उसके interface के ज़रिए चलती है। GitHub की write permission का इस्तेमाल नतीजे pull requests और commits पर वापस पोस्ट करने के लिए होता है, न कि code push करने या workflow files बदलने के लिए।
जब interface जान-बूझकर बदला जाए, तब tests का क्या होता है?
जो test किसी खास element से नहीं बल्कि business flow से जुड़ा है, वह ऐसे redesign में बच जाता है जो flow को नहीं बदलता। और जब flow ही बदल जाए, तो वह नया behavior है और उसके लिए नया या अपडेटेड case चाहिए, जिसे agent उसी बदलाव से बना सकता है।
क्या मैं इसे किसी branch पर चला सकता हूँ, बिना main suite पर असर डाले?
tests किसी git branch के नहीं, application के होते हैं, इसलिए एक ही मानक suite रहती है। अगर आपको हर branch पर जाँच चाहिए तो pull request trigger चुनिए, और अगर हर merge के बाद एक साझा environment जँचवाना है तो push trigger।
diff पढ़ना बंद कीजिए। app चलाइए।
Cursor bugs, state, timing और integration की सीमाओं में छिपते हैं — ठीक उन्हीं जगहों पर जहाँ static पढ़ाई और mock वाला test पहुँच ही नहीं सकते। verification agent के हाथ में दीजिए, उसे deployed build पर लगाइए, और pull request को ही बताने दीजिए कि किसी के merge करने से पहले बदलाव काम करता है या नहीं।