एका कमांडने ब्राउझरमध्ये तुमच्या ॲपची चाचणी करा

प्रोजेक्ट चॅटमध्ये /test टाइप करा आणि Mythex एखादी व्यक्ती करेल तसे तुमच्या ॲपची चाचणी करते: browser मध्ये live preview उघडते, पाने भेट देते, बटणांवर क्लिक करते आणि फॉर्म भरते, आणि मग चॅटमध्ये काय चालले आणि काय नाही ते सांगते. तुम्ही एखाद्या विशिष्ट flow कडे लक्ष देऊ शकता — "signup आणि pricing पाने तपासा" — किंवा ॲपमधील स्पष्ट मार्ग घेऊ द्या.

हे काय करते

App Testing तुमच्या live preview ची चाचणी करते, फक्त तुमचा कोड नव्हे. Mythex चालणाऱ्या ॲपविरुद्ध browser चालवते, त्याला जे दिसते ते टिपते — उपयुक्त असतील तेव्हा screenshots सह — आणि निकालांचा सारांश चॅटमध्ये लिहिते.

ती स्रोत कोड वाचण्यापेक्षा वेगळ्या प्रकारची तपासणी आहे. कोड बरोबर दिसू शकतो आणि तरीही वापरताना अयशस्वी होऊ शकतो: चुकीच्या handler ला जोडलेले बटण, पुष्टी न दाखवणारा फॉर्म, किंवा लॉगिन केल्यावरच तुटणारे पान. ते शोधण्याचा एकमेव मार्ग म्हणजे ॲप वापरणे, आणि App Testing ते तुमच्यासाठी करते.

हे का उपयुक्त आहे

Agent सह बांधताना, preview हा प्रगती मोजण्याचा मार्ग असतो. तुम्ही क्लिक करता, सर्व ठीक वाटते, तुम्ही पुढे जाता. पण प्रत्येक बदलानंतर प्रत्येक flow पुन्हा क्लिक करणे कंटाळवाणे होते, आणि तुम्ही नुकतेच बदललेले पान तपासता आणि शांतपणे तुटलेले दुसरे पान चुकता.

App Testing "अजून सर्व चालते का?" हा प्रश्न एका संदेशात बदलते. तुम्ही महत्त्वाचा मार्ग वर्णन करता, agent तो चालवतो, आणि तुम्हाला कृती करता येईल असा अहवाल मिळतो. ते त्याच चॅटमध्ये चालत असल्यामुळे दुरुस्ती एक संदेश दूर असते.

कसे चालवायचे

1. Preview चालू असल्याची खात्री करा आणि त्यात तुमचे ॲप दिसत असावे. App Testing preview विरुद्ध चालते, त्यामुळे preview रिकामा असेल किंवा सुरू होत असेल तर थांबा किंवा आधी ते दुरुस्त करा.
2. प्रोजेक्ट चॅटमध्ये /test टाइप करा. "browser मध्ये ॲपची चाचणी करा" असे साध्या भाषेतही विचारू शकता.
3. लक्ष कशावर द्यायचे ते सांगा, हवे असल्यास. उदाहरणार्थ: "signup आणि pricing पाने तपासा", किंवा "खाते तयार करा, वस्तू जोडा, checkout करा".
4. अहवाल वाचा. Mythex काय प्रयत्न केले आणि काय चुकले याचा सारांश देते, उपयुक्त तिथे screenshots सह.
5. सापडलेले दुरुस्त करा /fix ने किंवा नेहमीच्या Build संदेशाने.
6. दुरुस्ती योग्य झाली आणि इतर काही तुटले नाही याची खात्री करण्यासाठी /test पुन्हा चालवा.

केव्हा वापरावे

• मोठ्या UI बदलानंतर. नवीन मांडणी किंवा navigation तुम्ही थेट न बदललेले flows तोडू शकते.
• प्रकाशित करण्यापूर्वी, visitors आधी स्पष्ट तुटलेपणा पकडण्यासाठी.
• Preview ठीक दिसतो पण एखादा flow ठीक नसेल तेव्हा. बहु-टप्प्यांचे मार्ग — signup, मग login, मग काहीतरी — तपासण्यासारखे सर्वात जास्त असतात.

चांगले निकाल कसे मिळवायचे

विनंती जितकी स्पष्ट, तितका अहवाल उपयुक्त.

• Happy path वर्णन करा. "खाते तयार करा, वस्तू जोडा, checkout करा" agent ला स्पष्ट क्रम आणि तपासण्यासाठी स्पष्ट निकाल देतो. "सर्व काही तपासा" म्हटले तर काय महत्त्वाचे आहे याचा अंदाज agent ला लावावा लागतो.
• तुम्ही बदललेली पाने किंवा फीचर्स नाव द्या. नुकतेच pricing पान पुन्हा बांधले असेल तर तसे सांगा.
• लहान फेऱ्यांमध्ये चाचणी करा. एखादी गोष्ट बदला, तपासा, दुरुस्त करा, पुन्हा तपासा. फक्त एक गोष्ट बदलली असेल तर काय तुटले ते पाहणे सोपे.
• Checkpoints सोबत वापरा. एखादा बदल जितके दुरुस्त केले त्याहून जास्त तोडत असेल, तर त्यावर पॅच करण्याऐवजी शेवटच्या चांगल्या turn वर परत जा.

मर्यादा

• ते प्रकाशित साइटची नव्हे, preview ची चाचणी करते. App Testing तुमच्या खासगी workspace मधील live preview विरुद्ध चालते. ते visitors ना दिसणाऱ्या published URL ची तपासणी करत नाही. तयार झाल्यावर स्वतंत्रपणे प्रकाशित करा.
• Preview चालू असला पाहिजे. तो चालू नसेल तर चाचणी करण्यासारखे काही नसते.
• तुम्ही दाखवलेल्या मार्गांनुसार चालते. केंद्रित विनंतीला केंद्रित तपासणी मिळते; ती संपूर्ण test suite नाही.
• अहवाल देते; निर्णय तुमचा. App Testing काय तुटले ते सांगते. दुरुस्ती वेगळी पायरी आहे, /fix किंवा Build संदेशाने.

एकदा समस्या सापडल्यावर तिचा माग काढण्याबद्दल अधिक खोलात जायचे असेल, तर आमचे AI ने बनवलेले ॲप कसे debug करायचे हे मार्गदर्शक प्रक्रिया समजावते. Preview स्वतःबद्दल, प्रत्येक प्रोजेक्टसाठी खासगी workspace आणि live preview पहा.

तपशीलवार माहिती docs पानावर आहे: App Testing.