मैं वास्तव में GitHub कोपायलट के साथ सबसे पहले टेस्ट कैसे लिखता हूं (खुद से झूठ बोले बिना)
परीक्षण-संचालित विकास विफल हो जाता है क्योंकि परीक्षण लिखना कोड लिखने की तुलना में धीमा है। को-पायलट गणित को पलट देता है, और यही वर्कफ़्लो है जहाँ यह वास्तव में काम करता है।
प्रत्येक डेवलपर परीक्षण में विश्वास करता है जिस तरह से हर कोई फ्लॉसिंग में विश्वास करता है, और परीक्षण-प्रथम विकास उसी कारण से विफल हो जाता है: जब आप प्रवाह में होते हैं, तो परीक्षण लिखना कागजी काम करने के लिए रुकने जैसा लगता है। कोपायलट ने मेरे लिए गणित बदल दिया, परीक्षणों को सुखद बनाकर नहीं बल्कि उन्हें इतना तेज़ बनाकर कि कागजी कार्रवाई की आपत्ति गायब हो गई। यह वह कार्यप्रवाह है जहां यह वास्तव में कायम रहता है।
चाल यह है कि परीक्षण को एक विशिष्टता के रूप में लिखा जाए और कोपायलट को बॉयलरप्लेट करने दिया जाए। कार्यान्वयन को छूने से पहले, मैं परीक्षण नाम में परिदृश्य के साथ एक असफल परीक्षण और सामान्य भाषा में अपेक्षित व्यवहार का वर्णन करने वाली एक टिप्पणी लिखता हूं। कोपायलट आश्चर्यजनक क्षमता के साथ दावे, मॉकिंग और सेटअप को भरता है, क्योंकि परीक्षण फ़ाइलें बिल्कुल उसी प्रकार के पैटर्न वाले कोड हैं जिनमें यह उत्कृष्टता प्राप्त करता है। मेरा काम यह समीक्षा करना है कि क्या परीक्षण सही चीज़ का परीक्षण करता है, जो एक निर्णय कॉल है, टाइपिंग नहीं।
परिदृश्यों को बैच करें, एक समय में एक फ़ंक्शन। मैं शुरू करने से पहले मामलों को सूचीबद्ध करता हूं, खुश पथ, खाली इनपुट, सीमा, त्रुटि, फिर कोपायलट उन्हें एक पास में उत्पन्न करता है और सेट की एक साथ समीक्षा करता है। एक सेट के रूप में पांच परीक्षणों की समीक्षा करने से पता चलता है कि एक-एक करके उनकी समीक्षा करने से क्या छूट जाता है: गायब मामला, आमतौर पर अजीब मामला जो आपके कोडबेस को पहले काट चुका है। मेरे प्री-फ़्लाइट प्रॉम्प्ट में अब इस मॉड्यूल में पिछली उत्पादन घटनाओं को सूचीबद्ध करने वाली एक टिप्पणी पंक्ति शामिल है, क्योंकि मॉडल उस संदर्भ को तब तक नहीं जान सकता जब तक आप उसे नहीं बताते।
एआई के साथ परीक्षण-प्रथम का ईमानदार हिस्सा यह जानना है कि यह कहां गुमराह करता है। सह-पायलट खुशी-खुशी एक परीक्षण लिखेगा जो आपकी गलत धारणाओं को प्रतिबिंबित करता है, और साझा गलतफहमियों पर बनाया गया एक हरा सूट बिना किसी सूट से भी बदतर है, क्योंकि यह बग का बचाव करता है। मारक सस्ता और गैर-परक्राम्य है: लागू करने से पहले, परीक्षण चलाएं और देखें कि यह सही कारण से विफल हो रहा है, फिर जानबूझकर अपेक्षित आउटपुट को दावे में तोड़ दें और पुष्टि करें कि परीक्षण इसे पकड़ लेता है। प्रति परीक्षण तीस सेकंड जो सुइट को ईमानदार रखता है।
इससे मुझे व्यवहार में क्या मिला: उबाऊ रास्तों पर कवरेज, इनपुट सत्यापन और त्रुटि प्रबंधन, जो मैं कभी नहीं लिखता था, क्योंकि लागत लगभग शून्य हो गई थी। इसने मुझे क्या नहीं दिया: कोड को क्या करना चाहिए, इसके बारे में सोचने से बचने का एक बहाना, जहां टेस्ट-फर्स्ट को हमेशा वैसे भी मदद करनी चाहिए थी। लाल-हरा-रिफैक्टर लय बरकरार रहती है; को-पायलट ने उस हिस्से को हटा दिया जहां लाल परीक्षण लिखना एक कर की तरह महसूस होता था।
