यूनिट परीक्षण निर्माण में तेजी लाना और कोड गुणवत्ता में सुधार करना

हाल ही में, मुझे स्वचालित इकाई परीक्षण पीढ़ी के लिए डिज़ाइन किए गए एआई एजेंट अर्ली के बारे में गहराई से जानने का अवसर मिला। एक ऐसे व्यक्ति के रूप में जो नियमित रूप से टाइपस्क्रिप्ट और एक्सप्रेसओटीएस फ्रेमवर्क के साथ काम करता है, मैं यह देखने के लिए उत्सुक था कि अर्ली मेरे वर्कफ़्लो को कैसे सुव्यवस्थित कर सकता है। मैंने अपनी नई एनपीएम लाइब्रेरी पर उनके द्वारा बनाए गए vscode एक्सटेंशन का परीक्षण करने का निर्णय लिया, जिसे मैं @expressots/share नाम से विकसित कर रहा था।

आरंभिक प्रभाव

अर्ली के बारे में पहली चीज़ जिसने मुझे प्रभावित किया, वह थी मेरे मौजूदा कोडबेस के लिए स्वचालित रूप से यूनिट परीक्षण उत्पन्न करने की इसकी क्षमता। खरोंच से परीक्षण तैयार करने के बजाय, मैं उत्पन्न परीक्षणों को परिष्कृत करने और अपने कोड की मजबूती और परीक्षण क्षमता में सुधार करने पर ध्यान केंद्रित कर सकता हूं। इस बदलाव से मेरी विकास प्रक्रिया में काफी तेजी आई। दूसरा दिलचस्प पहलू जो मैंने देखा वह यह है कि जेनरेट किए गए 83% कोड में मैंने कोई समायोजन नहीं किया, इसने बॉक्स से बाहर काम किया और मेरे कोड कवरेज को बढ़ा दिया। मेरा बहुत सारा समय बचाएं।

समय की बचत और बढ़ी हुई कवरेज

केवल 8.5 घंटों में, मैं यह करने में कामयाब रहा:

• कोड की लगभग 3,000 पंक्तियों के लिए यूनिट परीक्षण उत्पन्न करें।
• समस्याओं को ठीक करें और कोड परीक्षण क्षमता को बढ़ाएं।
• 96 परीक्षणों के साथ 88% का कुल कोड कवरेज प्राप्त करें।

यह तथ्य कि मैं यह सब एक ही दिन में पूरा कर सका, उल्लेखनीय था। यूनिट परीक्षण में आदर्श परिदृश्य यह है कि इसे तब करें जब आप वास्तव में अपने कार्यों का विकास कर रहे हों। मैंने ऐसा इस तथ्य के बाद किया कि मेरे पास पहले से ही एक लाइब्रेरी थी, इसलिए कोड को परीक्षण योग्य बनाने के लिए कुछ समायोजन आवश्यक थे।

सकारात्मक परिणाम

एज केस टेस्ट की स्वचालित पीढ़ी। उदाहरण के लिए, इसने खाली स्ट्रिंग वाले परिदृश्यों के लिए यूनिट परीक्षण तैयार किया, तब भी जब पैरामीटर की आवश्यकता थी:

export function printSuccess(message: string, component: string): void {
  stdout.write(chalk.green(`${message}:`, chalk.bold(chalk.white(`[${component}] ✔️\n`))));
}

प्रारंभ में, मैंने इतने सीधे फ़ंक्शन में खाली स्ट्रिंग्स के लिए परीक्षण नहीं बनाया होता। हालाँकि, अर्ली के दृष्टिकोण ने रक्षात्मक प्रोग्रामिंग प्रथाओं को बढ़ावा दिया, जिससे मुझे उन किनारे वाले मामलों को संभालने के लिए प्रेरित किया गया जिन्हें मैंने अनदेखा कर दिया था।

संभावित मुद्दों का पता लगाना

जनरेटेड परीक्षणों को परिष्कृत करते समय, मुझे एक प्रकार की बेमेल समस्या का सामना करना पड़ा:

समस्या: jest.fn() कोई भी रिटर्न देता है, लेकिन प्रोसेस.एग्जिट कभी नहीं लौटाता, जिससे टाइपस्क्रिप्ट में एक प्रकार का बेमेल हो जाता है।
समाधान: प्रकार की शुद्धता सुनिश्चित करते हुए, प्रोसेस.एग्जिट हस्ताक्षर से मेल करने के लिए मॉक को संशोधित करें।
इस खोज ने मुझे बेहतर प्रकार की सुरक्षा के लिए अपने कोड को समायोजित करने के लिए प्रेरित किया, जिससे इस बात पर प्रकाश डाला गया कि कैसे अर्ली सूक्ष्म मुद्दों की पहचान करने में मदद कर सकता है जो अन्यथा किसी का ध्यान नहीं जा सकता।

सुधार के क्षेत्र

समग्र सकारात्मक अनुभव के बावजूद, मुझे कुछ चुनौतियों का सामना करना पड़ा, जिनका यदि समाधान किया जाए, तो अर्ली की उपयोगिता बढ़ सकती है:

• लाइब्रेरी संस्करण संगतता। कुछ मामलों में अप्रचलित जेस्ट विधियों का उपयोग करके प्रारंभिक उत्पन्न परीक्षण, उदाहरण के लिए:

जेस्ट 29.7 का उपयोग करना

expect(Compiler.loadConfig()).rejects.toThrowError("process.exit() was called with code 1");

// संशोधित संस्करण

expect(Compiler.loadConfig()).rejects.toThrow("process.exit() was called with code 1");

• टेस्ट जनरेशन के लिए अनुकूलन विकल्प हालांकि किनारे के मामलों के लिए परीक्षण तैयार करना फायदेमंद था, कुछ परिदृश्यों में, यह आवश्यक नहीं हो सकता है:

अवलोकन: खाली स्ट्रिंग्स सहित हर संभावित इनपुट के लिए परीक्षण उत्पन्न करना कभी-कभी अत्यधिक हो सकता है।

सुझाव: परीक्षण पीढ़ी के स्तर को अनुकूलित करने के लिए विकल्प पेश करें, जिससे डेवलपर्स आवश्यकतानुसार रक्षात्मक प्रोग्रामिंग परीक्षणों के लिए ऑप्ट-इन कर सकें।

• VSCODE एक्सटेंशन में उपयोगकर्ता इंटरफ़ेस संवर्द्धन अर्ली और अन्य टूल के बीच नेविगेट करने से कुछ यूआई सीमाएँ उजागर हुईं:

परीक्षण परिणाम दृश्यता: मुझे यह देखने के लिए अर्ली और जेस्ट के बीच स्विच करना पड़ा कि कौन से परीक्षण सफल हुए या असफल।

फ़ाइल ट्री स्थिति: अन्य अनुप्रयोगों से वापस स्विच करने पर प्रारंभिक प्रोजेक्ट पदानुक्रम ढह जाता है, जिससे मुझे बार-बार फ़ोल्डर्स को फिर से खोलने की आवश्यकता होती है।
सुझाव: जेस्ट की संरचना को प्रतिबिंबित करते हुए, अर्ली में परीक्षण परिणाम प्रदर्शित करने के लिए यूआई में सुधार करें। फ़ाइल ट्री की स्थिति बनाए रखने से उपयोगकर्ता अनुभव भी बेहतर होगा।

• मॉकिंग और टाइप सेफ्टी jest.fn() द्वारा किसी भी रिटर्न को वापस करने की समस्या अधिक सटीक मॉकिंग की आवश्यकता का सुझाव देती है:

अवलोकन: मॉक में किसी भी प्रकार का उपयोग करने से टाइप बेमेल हो सकता है और संभावित रूप से बग छिप सकते हैं।
सुझाव: सटीक हस्ताक्षरों का उपयोग करने के लिए नकली पीढ़ी को परिष्कृत करें, बेहतर प्रकार की सुरक्षा को बढ़ावा दें और मैन्युअल सुधार की आवश्यकता को कम करें।

निष्कर्ष

कुल मिलाकर, अर्ली के साथ मेरा अनुभव बेहद सकारात्मक था। टूल ने मेरी यूनिट परीक्षण प्रक्रिया को काफी तेज कर दिया, जिससे मुझे स्क्रैच से लिखने के बजाय परीक्षणों को परिष्कृत करने पर ध्यान केंद्रित करने की अनुमति मिली। इसने मुझे किनारे के मामलों पर विचार करने और अपने कोड की मजबूती में सुधार करने के लिए भी प्रोत्साहित किया।

सुधार के क्षेत्र अपेक्षाकृत छोटे हैं और प्रयोज्यता और अनुकूलन को बढ़ाने के इर्द-गिर्द घूमते हैं। इन्हें संबोधित करने से उपकरण सॉफ्टवेयर विकास में और भी अधिक शक्तिशाली सहयोगी बन जाएगा।

प्रारंभिक टीम को उनके उत्कृष्ट कार्य के लिए बधाई! मैं यह देखने के लिए उत्साहित हूं कि टूल कैसे विकसित होता है और इसे और बेहतर बनाने में मदद करने के लिए फीडबैक देना जारी रखने में खुशी होगी।