Meta में बड़े भाषा मॉडल (LLM) से स्वचालित यूनिट टेस्ट सुधार

 (arxiv.org)
2 पॉइंट द्वारा GN⁺ 2024-02-19 | 1 टिप्पणियां | WhatsApp पर शेयर करें

Meta का ऑटोमेटेड यूनिट टेस्ट सुधार टूल: TestGen-LLM

  • Meta द्वारा विकसित TestGen-LLM टूल बड़े भाषा मॉडल (LLMs) का उपयोग करके पहले से मौजूद मानव-लिखित टेस्टों को स्वतः सुधारता है।
  • TestGen-LLM से उत्पन्न टेस्ट क्लासें मूल टेस्ट सूट की तुलना में मापनीय सुधार सुनिश्चित करने वाले कई फ़िल्टर सफलतापूर्वक पार करती हैं, जिससे LLM hallucination समस्या का समाधान होता है।
  • Meta के Instagram और Facebook प्लेटफ़ॉर्म के लिए आयोजित test-a-thons में TestGen-LLM की deployment का विवरण दिया गया है।

TestGen-LLM का प्रदर्शन मूल्यांकन

  • Instagram के Reels और Stories उत्पादों पर किए गए मूल्यांकन में TestGen-LLM के टेस्ट केसों में से 75% सही तरह से build हुए, 57% विश्वसनीय रूप से पास हुए, और 25% ने coverage बढ़ाई।
  • Meta के Instagram और Facebook टेस्ट-a-thons में TestGen-LLM ने लागू की गई सभी क्लासों में से 11.5% सुधार की, और Meta software engineers ने production rollout के लिए 73% सुझाव स्वीकार किए।
  • यह LLM द्वारा जनरेट किए गए कोड के industrial-scale deployment पर पहली रिपोर्ट है, जिसमें कोड सुधार के लिए ऐसा भरोसा दिया गया है।

GN⁺ की राय

  • TestGen-LLM एक ऐसा टूल है जो सॉफ्टवेयर टेस्टिंग के ऑटोमेशन और गुणवत्ता सुधार में बदलाव ला सकता है क्योंकि यह LLM की मदद से पहले से मौजूद टेस्टों को बेहतर करने में सफल रहा है।
  • यह टूल वास्तविक औद्योगिक माहौल में टेस्ट कवरेज बढ़ाता है और विश्वसनीय टेस्ट केस बनाकर सॉफ्टवेयर इंजीनियरिंग समुदाय के लिए महत्वपूर्ण योगदान देता है।
  • Meta के टेस्ट-a-thons में इसका सफलतापूर्वक उपयोग यह दर्शाता है कि TestGen-LLM को वास्तविक product development में integrate किया जा सकता है, जिससे सॉफ्टवेयर निर्माण की efficiency और reliability बेहतर हो सकती है।

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-02-19
Hacker News टिप्पणी
  • एक बड़ी इंश्योरेंस कंपनी में मैनेजर्स ने पूरे कोडबेस के लिए 80% टेस्ट कवरेज का लक्ष्य तय किया था। उसके बाद डेवेलपर्स ने यह लक्ष्य पाने के लिए जावा DTO के गेटर और सेटर के लिए बेसिक यूनिट टेस्ट लिखने शुरू कर दिए। एक युवा डेवेलपर के तौर पर, इस अनुभव ने दिखाया कि अगर केवल KPI पर फोकस किया जाए तो व्यवहार संगठन के असली उद्देश्य से अलग दिशा में जा सकता है। कुछ अच्छे से डिज़ाइन किए गए E2E टेस्ट सीनारियो शायद सॉफ़्टवेयर क्वालिटी पर कहीं बेहतर असर डालते।
  • LLM-जनित टेस्ट की दिक्कत यह है कि वे बग वाले व्यवहार को भी "सही/पास" कर सकते हैं। खासकर जब codebase की टेस्ट कवरेज पहले से ही कम हो। जब टेस्ट मैन्युअली लिखे जाते हैं, तो किसी इंसान के पास यह जज करने की क्षमता रहती है कि सिस्टम गलत है या टेस्ट ही गलत है। कम-से-कम ऐसे टेस्टों को अलग टेस्ट फोल्डर में अलग से और उचित स्तर की शंका/सावधानी के साथ हैंडल करना चाहिए।
  • PDF पढ़कर लगता है कि यह बस ऐसे टेस्ट बनाने पर केंद्रित है जो बार-बार पास हों यानी unstable न हों। मुख्य उद्देश्य पुराने कोड के व्यवहार को लॉक करने वाला एक regression टेस्ट suite बनाना है। यह डेवेलपरों द्वारा लिखे टेस्ट का replacement नहीं है; डेवेलपर-लिखित टेस्ट में अपेक्षा की जाती है कि वे फीचर requirements को जानते हैं।
  • करीब 20 साल पहले जिस कंपनी में मैंने काम किया था, वहाँ हमने AgitarOne ट्राई किया था। यह जावा कोड के लिए टेस्ट केस ऑटोमेटिकली जनरेट करके उसके behavior को explore करने में मदद करेगा, ऐसा दावा था। लेकिन Agitar भी ऑटोमैटिकली पास होने वाले टेस्ट बना सकता था और उन्हें regression suite की तरह यूज़ किया जा सकता था। मुझे व्यक्तिगत तौर पर यह तरीका पसंद नहीं आया। मैनेजर्स को लगा कि टेस्ट कवरेज बढ़ी मतलब क्वालिटी बढ़ गई। मुझे उत्सुकता है कि LLM एप्रोच Agitar से कितना बेहतर है।
  • टेस्ट लिखना सामान्यतः कोड क्वालिटी को समझने का अच्छा तरीका है। अगर टेस्ट लिखना कठिन हो या कवरेज हासिल करना मुश्किल हो रहा हो, तो संभव है कि टेस्ट किए जा रहे कोड में सुधार की जरूरत ज्यादा हो।
  • unlogged.io ने कुछ समय तक ऑटोमेटिक junit टेस्ट जनरेट करने पर फोकस किया था। कई कारणों से यह एप्रोच सफल नहीं हो पाया: 1) इतना ज्यादा generated टेस्ट कोड जो डेवेलपर्स मेंटेन नहीं करना चाहते थे, 2) वास्तविक दुनिया के scenarios को simulate न करने वाले generated टेस्ट, 3) coverage को vanity metric की तरह इस्तेमाल करना। अब यह सभी unique production scenarios को simulate करने वाले नो-कोड replay टेस्ट देने पर फोकस कर रहा/रही है। संदर्भ के लिए, मैं unlogged.io का फ़ाउंडर हूँ।
  • उलटा सोचने की इच्छा है: पहले acceptance criteria डालें, फिर उसे validate करने वाले टेस्ट generate करें, और केवल वही कोड generate करें जो उन टेस्ट को पास करे। Copilot के साथ कभी-कभी सीमित तरीके से इस दिशा में गया जा सकता है, लेकिन समझ नहीं आता कि क्यों कोई भी इस approach पर सच में focus नहीं कर रहा।
  • TestGen-LLM एक अजीब निर्माण है। शायद इसे refactoring या rewrite के पहले चरण में इस्तेमाल किया जा सकता है, लेकिन पेपर में code coverage पर ज़ोर रखना सच में उल्टा लगता है। अगर किसी संगठन का दिमाग पहले से ही high coverage को ही target करके गड़बड़ा गया हो, तब शायद ठीक हो; लेकिन TestGen-LLM प्रोजेक्ट के कोड को किसी तरीके से बेहतर नहीं करेगा और वास्तविक सुधार लागू करने में अतिरिक्त friction बढ़ाएगा। सिर्फ compiler errors और फेल हुए टेस्ट पर भरोसा करके LLM-generated garbage को filter करने वाला TestGen-LLM, पास भी होने वाले और पास न भी होने वाले edge-case टेस्ट generate कर सकता है, जो कहीं ज्यादा useful होगा। पेपर में generated टेस्ट के कोई उदाहरण नहीं दिए गए हैं, इसलिए शक है कि वे बाकी LLM-generated code की तरह amateur ही होंगे, जैसा मैंने पहले देखा है।
  • भविष्य में इतने बड़े autogenerated टेस्ट कॉर्पस को maintain करने की लागत कितनी होगी, यह पूछना स्वाभाविक है। सिर्फ केस जनरेट करना ही नहीं, उन्हें अपडेट करने के लिए automated तरीका भी provide करना पड़ेगा।
  • यह सच में अच्छी बात है कि Meta के कर्मचारी developers के लिए AI pitch करने के लिए 12-पेज का paper लेकर आए। उन्होंने तो Sankey diagram तक इस्तेमाल किए। शायद इसमें गलती भी हो सकती है, लेकिन अगर इस तरह publish किया गया हो तो reproducible details देनी चाहिए। Meta को सीखने के लिए डेटा चाहिए, शायद इसलिए उन्होंने कुछ चीजें शेयर कीं।
  • Instagram के Reels और Stories products पर किए गए eval में TestGen-LLM के टेस्ट केसों में से 75% सही तरह से बनाए गए, 57% reliably पास हुए, और सिर्फ 25% ने coverage बढ़ाई। परिणाम अच्छे नहीं लगते, क्या ऐसा नहीं लगता?