ईमानदार शुरुआत
अगर आप कोड पढ़ नहीं सकते, तो आप कोड रिव्यू भी नहीं कर सकते — और इसका बुरा मानना छोड़ दीजिए। इसका विकल्प रिव्यू करना नहीं है; व्यवहार को जाँचना है। आपके यूज़र वैसे भी यही करेंगे, और इससे समस्याओं की एक ऐसी श्रेणी पकड़ में आती है जो कोड पढ़ने से छूट जाती।
Lovable code bugs आमतौर पर कहाँ छिपे होते हैं
जेनरेट किए गए ऐप एक अंदाज़े लायक क्रम में टूटते हैं। सबसे पहले इन्हें जाँचें।
| दिखता है कि सेव हो गया, हुआ नहीं | फ़ॉर्म सफलता का मैसेज दिखाता है, और रिफ़्रेश करते ही रिकॉर्ड ग़ायब। किसी भी सेव पर भरोसा करने से पहले हमेशा पेज रीलोड करें। |
| खाली और एरर स्टेट | हैपी पाथ बनाया भी गया और दिखाया भी गया। शून्य नतीजों और फ़ेल हुई रिक्वेस्ट वाले मामले अक्सर नहीं बने होते। इसे बिना किसी डेटा के आज़माएँ, और जान-बूझकर ग़लत इनपुट देकर भी। |
| दूसरा यूज़र | जिस अकाउंट ने इसे बनाया है, उसके लिए सब कुछ काम करता है। बाक़ी किसी के लिए सबसे पहले परमिशन, ओनरशिप और विज़िबिलिटी टूटती हैं। किसी को दिखाने से पहले दूसरे अकाउंट से साइन इन करके देखें। |
वह जाँच जो लगातार काम करती रहे
हाथ से जाँचना वीकेंड प्रोजेक्ट के लिए ठीक है, लेकिन जैसे ही आप prompting करते रहते हैं, यह टिक नहीं पाता। हर नया निर्देश चुपचाप उस चीज़ को बिगाड़ सकता है जो कल तक चल रही थी, और हर बार मैनुअल जाँच पिछली बार से छोटी होती जाती है।
आप चाहते हैं कि जाँचें लिखित रूप में दर्ज हों और अपने आप चलें — टेस्ट कोड में नहीं, बल्कि सीधी-सादी भाषा में लिखी हुई। सेटअप यह क्षमता एजेंट के हाथ में दे देता है, ताकि बनाने के साथ-साथ जाँच भी चलती रहे।
यह सब TestSprite डैशबोर्ड में भी मौजूद है, और अगर आपका काम टर्मिनल में नहीं होता तो आमतौर पर यही बेहतर रास्ता है। CLI का पूरा ब्यौरा यहाँ है — CLI रिपॉज़िटरी।
तीन जाँचें, जो पहले दिन से होनी चाहिए
साइन अप करें, फिर दोबारा साइन इन करें। जेनरेट किए गए ऐप कहीं और से ज़्यादा यहीं टूटते हैं, और असली यूज़र सबसे पहले यही करता है।
कुछ बनाइए, रीलोड कीजिए, और पक्का कीजिए कि वह अब भी वहीं है। यह अकेली जाँच सबसे आम और सबसे शर्मिंदा करने वाली गड़बड़ी पकड़ लेती है।
अपने ऐप का जो एक मुख्य काम है, उसे बिलकुल नए अकाउंट से करके देखिए। अगर वह किसी अनजान यूज़र के लिए चल गया, तो आपके पास कुछ है।
बग को ऐसे बताइए कि फ़िक्स सही जगह लगे
जब कुछ ग़लत होता है, तो मन करता है कि बस कह दें "यह टूटा हुआ है"। इससे एजेंट को बहुत कम मिलता है, और बदले में ऐसा बदलाव आता है जो आस-पास की किसी चीज़ को ठीक कर देता है।
तीन वाक्य इससे कहीं बेहतर काम करते हैं, और इनमें से किसी के लिए तकनीकी शब्दावली की ज़रूरत नहीं। आपने क्या किया, क्रम से। आपको क्या उम्मीद थी। उसकी जगह क्या हुआ। "मैंने फ़ॉर्म भरा और सेव दबाया, मुझे उम्मीद थी कि नया आइटम लिस्ट में दिखेगा, लेकिन रीलोड करने तक लिस्ट खाली रही" — यह सचमुच एक अच्छी बग रिपोर्ट है, और यह सीधे ख़राबी की ओर इशारा करती है।
यही तीन वाक्य आपकी टिकाऊ जाँच भी बन जाते हैं। एक बार लिख लेने के बाद इन्हें हर आगामी बदलाव के बाद दोबारा चलाया जा सकता है, और इसी तरह वही समस्या लौटने से रुकती है।
जाँच किस क्रम में करें
एक ऐसा क्रम है जो यूँ ही इधर-उधर क्लिक करने से जल्दी समस्याएँ ढूँढ़ निकालता है, और इसमें करीब दस मिनट लगते हैं।
शुरुआत साइन आउट की हालत से करें और बिलकुल नए यूज़र की तरह साइन अप करें, क्योंकि यही रास्ता आपने ख़ुद सबसे कम इस्तेमाल किया है। फिर आपका ऐप जिस एक काम के लिए बना है, उसे आख़िर तक पूरा करें, और कुछ भी मानने से पहले पेज रीलोड करें। फिर वही काम ग़लत तरीके से दोहराएँ: कोई ज़रूरी फ़ील्ड खाली छोड़ दें, जहाँ नंबर चाहिए वहाँ टेक्स्ट डालें, कुछ बेतुका अपलोड करें। फिर कुछ डिलीट करें और पक्का करें कि वह वाक़ई हट गया है, सिर्फ़ छिपा नहीं है।
इन चारों में से हर एक में एक-दो मिनट लगते हैं और हर एक उस समूह से जुड़ा है जहाँ जेनरेट किए गए ऐप टूटते हैं। इन्हें इसी क्रम में करना मायने रखता है, क्योंकि टूटा हुआ साइनअप उसके बाद की हर चीज़ को अनटेस्टेबल बना देता है, और लोग अक्सर ऐसे फ़ीचर पर एक घंटा लगा देते हैं जिस तक कोई पहुँच ही नहीं सकता।
जब आप इसे साझा करने के लिए तैयार हों
ऐप के किसी असली जगह पहुँचने से पहले, जाँचें हर बदलाव पर अपने आप चलें — तब नहीं जब आपको याद आ जाए। ऐसा करने के दो तरीके हैं:
डैशबोर्ड से रिपॉज़िटरी कनेक्ट कर दें और रन उसी डिप्लॉयमेंट से शुरू हो जाएँगे जो आप पहले से बनाते हैं, या इसके बजाय अपने ही वर्कफ़्लो में एक स्टेप जोड़ लें।
TestSprite आपके लिए जाँच कैसे करता है
आप सीधी-सादी भाषा में बताते हैं कि क्या सही होना चाहिए, और क्लिक करने का काम TestSprite करता है। न टेस्ट कोड, न फ़्रेमवर्क, न टर्मिनल की ज़रूरत: डैशबोर्ड में एक प्रोजेक्ट बनाइए, उसे अपने ऐप की ओर इशारा कीजिए, और बता दीजिए कि चलता हुआ वर्ज़न कैसा दिखता है।
इस पेज में बताए गए चारों समूह ठीक वही हैं जिन्हें यह कवर करता है। यह नए अकाउंट से साइन अप करता है, कुछ बनाकर रीलोड करता है ताकि पक्का हो कि वह टिका रहा, कुछ ग़लत सबमिट करता है यह जाँचने के लिए कि ऐप ऐसा कहता है या नहीं, और वही फ़्लो दूसरे यूज़र की तरह चलाता है ताकि आपके अपने सेशन में बैठी परमिशन संबंधी मान्यताएँ पकड़ में आ जाएँ।
prompting जारी रखते हुए सबसे ज़्यादा मायने यह रखता है कि जाँचें बनी रहती हैं। हर बदलाव की पुष्टि उन सब चीज़ों के ख़िलाफ़ होती है जो उससे पहले काम कर रही थीं, और यही उस चक्र को रोकता है जिसमें एक चीज़ ठीक करते ही चुपचाप दूसरी बिगड़ जाती है।
क्या इसके लिए मुझे कोडिंग आनी चाहिए?
नहीं। जाँचें सीधी-सादी भाषा में लिखी जाती हैं और ऐप के इंटरफ़ेस के ज़रिए उसी तरह चलती हैं, जैसे कोई व्यक्ति उसे इस्तेमाल करता।
मेरा ऐप मेरे लिए क्यों चलता है और दूसरों के लिए क्यों नहीं?
आमतौर पर परमिशन या डेटा ओनरशिप की वजह से। जिस अकाउंट ने ऐप बनाया है, उसके पास ऐसे रिकॉर्ड और एक्सेस होते हैं जो नए अकाउंट के पास नहीं होते। दूसरे यूज़र बनकर टेस्ट करते ही यह तुरंत सामने आ जाता है।
और prompting करने से पहले टेस्ट करूँ या बाद में?
दोनों, और दूसरा ज़्यादा मायने रखता है। जो जाँच आपके ताज़ा निर्देश से पहले से मौजूद थी, वही बताती है कि उस निर्देश ने कुछ बिगाड़ा या नहीं।
अगर फ़िक्स बार-बार कुछ और बिगाड़ता रहे तो?
यह इस बात का संकेत है कि जाँचें आख़िर में नहीं, बल्कि लगातार चलनी चाहिए। हर बदलाव की पुष्टि उन सब चीज़ों के ख़िलाफ़ होती है जो उससे पहले काम कर रही थीं।
क्या यह सिर्फ़ Lovable के लिए है?
नहीं। जल्दी जेनरेट की गई किसी भी चीज़ में यही गड़बड़ियाँ दिखती हैं, चाहे उसे किसी ने भी बनाया हो। Lovable यूज़र इन तक पहले पहुँचते हैं क्योंकि वे जल्दी शिप करते हैं।
आप कोड रिव्यू नहीं कर सकते। व्यवहार जाँच सकते हैं।
ज़्यादातर Lovable code bugs यही होते हैं: ऐसे सेव जो टिकते नहीं, ग़ायब खाली स्टेट, और ऐसी चीज़ें जो सिर्फ़ उसी अकाउंट के लिए चलती हैं जिसने उन्हें बनाया। पहले इन तीनों को जाँचें, फिर ऐप साझा करने से पहले जाँचों को अपने आप चलने वाला बना दें।