AI वेब डेवलपमेंट टेस्टिंग को कहाँ देखना होता है
| स्टेप्स के बीच की स्टेट | एक फ़ॉर्म सबमिट होता है और उसके पीछे की लिस्ट रिफ़्रेश नहीं होती। एक फ़िल्टर उस स्क्रीन तक बना रहता है जहाँ उसका कोई मतलब नहीं। |
| टाइमिंग | डेटा से पहले रेंडर, या ऐसी रिक्वेस्ट जो कंपोनेंट के हट जाने के बाद पूरी होती है। |
| दूसरा यूज़र | ओनरशिप और विज़िबिलिटी को उसी सेशन के आधार पर मान लिया गया जिसमें वह बना था। |
इनमें से कोई भी diff में नहीं दिखता, इसीलिए तेज़ रिव्यू से मदद नहीं मिलती। ये चलती हुई ऐप को तीस सेकंड इस्तेमाल करने पर दिख जाते हैं, इसीलिए जाँच वहीं होनी चाहिए।
एजेंट के लिखे टेस्ट लूप को बंद क्यों नहीं करते
इम्प्लीमेंटेशन के साथ-साथ जेनरेट हुए टेस्ट उसी की मान्यताएँ अपना लेते हैं। अगर कोड यह मानता है कि कोई एंडपॉइंट 404 के बजाय खाली ऐरे लौटाता है, तो टेस्ट भी वही मान्यता असर्ट करता है और पास हो जाता है। आपको कवरेज मिलती है, स्वतंत्र सिग्नल नहीं।
लूप को बंद करने वाली जाँच को डिप्लॉय किए गए प्रोडक्ट को अपेक्षित व्यवहार के मुकाबले परखना होता है, न कि कोड की अपने बारे में बनी धारणा के मुकाबले।
इसे इतना तेज़ रखना कि वह वाकई इस्तेमाल हो
जिस वेरिफिकेशन स्टेप में फ़ीचर बनाने से ज़्यादा समय लगे, उसे छोड़ दिया जाएगा, और ठीक ही छोड़ा जाएगा। तीन चीज़ें इसे संतुलित रखती हैं: स्क्रीन के बजाय फ़्लो कवर करें, चेन छोटी रखें, और हर सेव पर नहीं बल्कि पुल रिक्वेस्ट पर चलाएँ।
लूप को इतना कसा हुआ रखना कि वह काम आए
जो वेरिफिकेशन स्टेप धीमा लगता है उसे छोड़ दिया जाता है, और छोड़ना समझदारी ही है, इसलिए रफ़्तार उतनी ही मायने रखती है जितनी कवरेज।
तीन चीज़ें इसे संतुलित रखती हैं। स्क्रीन के बजाय फ़्लो कवर करें, क्योंकि एक फ़्लो एक जाँच है और एक स्क्रीन पाँच। हर फ़्लो को उतने छोटे रास्ते तक सीमित रखें जिससे असली खराबी फिर भी पकड़ी जाए, यानी आमतौर पर दस नहीं बल्कि तीन या चार स्टेप। और बड़ी सुइट पुल रिक्वेस्ट पर चलाएँ, जबकि एक-दो जाँचें इतनी तेज़ रखें कि वे काम के दौरान ही चल सकें।
यही आख़िरी बँटवारा लोग अक्सर चूक जाते हैं। बनाते समय चलने वाली जाँच और मर्ज की रखवाली करने वाली जाँच का काम अलग-अलग है, और दोनों के लिए एक ही सुइट इस्तेमाल करने की कोशिश उसे या तो इतना धीमा बना देती है कि वह बार-बार न चले, या इतना हल्का कि उस पर भरोसा न हो।
इसे लूप में लाना
सेटअप वेरिफिकेशन स्किल को कोडिंग एजेंट में इंस्टॉल कर देता है, जिससे जाँच वहीं होती है जहाँ काम होता है, किसी अलग काम की तरह नहीं।
टर्मिनल
npm install -g @testsprite/testsprite-cli
testsprite setup
अगर आप कुछ भी इंस्टॉल नहीं करना चाहते, तो डैशबोर्ड वही काम करता है। कमांड लाइन जो कुछ और कर सकती है, वह सब यहाँ है — CLI रिपॉज़िटरी।
GitHub App एक वेबहुक है जिसे आप TestSprite डैशबोर्ड में सेट करते हैं। यह उसी डिप्लॉयमेंट इवेंट को सुनता है जो आपकी पाइपलाइन पहले से पैदा करती है, इसलिए आपकी रिपॉज़िटरी में कुछ भी नहीं बदलता।
GitHub Actions इस स्टेप को आपके अपने वर्कफ़्लो के भीतर रखता है, जिसे टर्मिनल से कॉन्फ़िगर किया जाता है।
TestSprite वह क्या वेरिफ़ाई करता है जो एजेंट नहीं कर सकता
डिप्लॉय किया गया एप्लिकेशन, इस आधार पर कि आपने क्या होना चाहिए यह कहा था, न कि इस आधार पर कि कोड क्या मान लेता है। यही स्वतंत्रता असल बात है: इम्प्लीमेंटेशन के साथ लिखे गए टेस्ट उसी की मान्यताएँ अपना लेते हैं, इसलिए वे उससे वहाँ भी सहमत रहते हैं जहाँ दोनों गलत हैं।
सेटअप वेरिफिकेशन स्किल को आपके कोडिंग एजेंट में इंस्टॉल कर देता है, जिससे जाँच बदलाव करने की प्रक्रिया का ही हिस्सा बन जाती है। स्टेप सेलेक्टर नहीं बल्कि इरादे होते हैं, और फ़ेल्योर एक ऐसे बंडल के रूप में वापस आता है जिस पर एजेंट सीधे काम कर सके, और यही फ़िक्स को बदलाव वाले उसी लूप में रखता है।
नतीजा यह कि स्टेट, टाइमिंग और दूसरे यूज़र वाली खराबियाँ किसी यूज़र के बजाय मर्ज से पहले पकड़ी जाती हैं, और वह भी ऐसे वेरिफिकेशन स्टेप के बिना जिसमें फ़ीचर से ज़्यादा समय लगे।
क्या इससे डेवलपमेंट धीमा होता है?
उस डिबगिंग से कम, जिसे यह रोकता है। तुलना शून्य लागत से नहीं है, बल्कि रिलीज़ के बाद उसी खराबी को पकड़ने से है।
क्या एजेंट अपने ही काम को टेस्ट कर सकता है?
वह जाँचें चला सकता है। जाँचें खुद इम्प्लीमेंटेशन से नहीं, अपेक्षित व्यवहार से आनी चाहिए, वरना आप अपना ही होमवर्क खुद जाँच रहे हैं।
उसने जो टेस्ट जेनरेट किए, उनका क्या?
उन्हें कवरेज के लिए रखें और उन्हें स्वतंत्र वेरिफिकेशन न मानें। वे बनावट से ही कोड से सहमत होते हैं।
शिप करने से पहले कितनी कवरेज?
वे फ़्लो जिनका टूटना आपके लिए शर्मिंदगी की बात होगी, और साथ में वह सब जो पैसे या परमिशन से जुड़ा हो। असली घटनाओं से आगे बढ़ाएँ।
क्या यह लोकल डेवलपमेंट के लिए काम करता है?
फ़्रंटएंड रन एक टनल के ज़रिए आपकी मशीन पर चल रही ऐप तक पहुँच सकते हैं, इसलिए कुछ भी डिप्लॉय होने से पहले ही जाँच उपलब्ध रहती है।
बनाना तेज़ हो गया। जाँच को बराबरी करनी होगी।
AI वेब डेवलपमेंट टेस्टिंग के लिए चलते हुए प्रोडक्ट के मुकाबले एक स्वतंत्र जाँच चाहिए, क्योंकि इम्प्लीमेंटेशन के साथ लिखे गए टेस्ट उसी की मान्यताएँ अपना लेते हैं। फ़्लो कवर करें, इसे संतुलित रखें, और इसे पुल रिक्वेस्ट पर चलाएँ।