Meta का नया LLM-आधारित टेस्ट जनरेटर
(read.engineerscodex.com)Meta का नया LLM-आधारित टेस्ट जनरेटर डेवलपमेंट के भविष्य की एक झलक देता है
- Meta ने "Automated Unit Test Improvement using Large Language Models at Meta" नामक एक पेपर प्रकाशित किया है.
- यह पेपर दिखाता है कि AI का उपयोग करके डेवलपमेंट की गति कैसे बढ़ाई जा सकती है और सॉफ्टवेयर बग कैसे कम किए जा सकते हैं.
- डेवलपर के workflow में LLM को इंटीग्रेट करते हुए, यह मौजूदा code coverage को बेहतर बनाने वाले सटीक और पूर्ण सॉफ्टवेयर सुधार प्रस्तावित करता है.
मुख्य बिंदु
- TestGen-LLM 'Assured LLM-based Software Engineering' (Assured LLMSE) दृष्टिकोण का उपयोग करता है.
- यह कई LLM, prompts और hyperparameters का उपयोग करके code improvement proposals बनाता है, और सबसे अच्छे सुधार को चुनने के लिए ensemble approach का उपयोग करता है.
- TestGen-LLM को खास तौर पर मौजूदा मानव-लिखित tests को बेहतर बनाने के लिए डिज़ाइन किया गया है.
आँकड़े
- Instagram के Reels और Stories प्रोडक्ट मूल्यांकन में, TestGen-LLM द्वारा बनाए गए 75% test cases सफलतापूर्वक build हुए, 57% भरोसेमंद तरीके से pass हुए, और 25% ने coverage बढ़ाया.
- TestGen-LLM लागू किए गए सभी classes में से 10% को सुधार सका, और डेवलपर्स ने 73% test improvements को स्वीकार कर production में लागू किया.
- Instagram की test coverage बढ़ाने के लिए tests बनाने वाले Meta इंजीनियरों के "test-a-thon" में, TestGen-LLM tests द्वारा जोड़ी गई code lines का median 2.5 था.
उपयोगी इनसाइट्स
- यह एक अच्छा उदाहरण है कि LLM का उपयोग करके डेवलपमेंट productivity और software reliability को प्रभावी ढंग से कैसे बढ़ाया जा सकता है.
- LLM की असली वैल्यू अप्रत्याशित edge cases को खोजने और पकड़ने में है.
- LLM को production में इस्तेमाल करने के लिए orchestration, pipelines और processing की आवश्यकता होती है.
TestGen-LLM कैसे काम करता है
- TestGen-LLM, Meta के internal LLM द्वारा तैयार किए गए candidate solutions पर semantic filters की एक श्रृंखला लागू करता है ताकि केवल सबसे मूल्यवान tests ही बचें.
- फ़िल्टर 1: buildability, फ़िल्टर 2: execution (test pass हुआ या नहीं), फ़िल्टर 3: flakiness, फ़िल्टर 4: coverage improvement.
- ये processing filters test suite में सुधार सुनिश्चित करते हैं.
निष्कर्ष
- यह पेपर उन कई डेवलपर्स के लिए, जो पहले से LLM का उपयोग कर रहे हैं, software reliability क्षेत्र में LLM की प्रगति को ट्रैक करने का एक अच्छा तरीका है.
- LLM धीरे-धीरे और अधिक जटिल software systems में bugs खोजने और tests करने में सक्षम होंगे.
GN⁺ की राय
- यह लेख दिलचस्प इनसाइट देता है कि artificial intelligence सॉफ्टवेयर डेवलपमेंट के भविष्य को कैसे प्रभावित कर सकती है.
- TestGen-LLM जैसे tools डेवलपर्स के काम को automate करने और efficiency बढ़ाने में बहुत मददगार हो सकते हैं.
- ऐसी तकनीकों की प्रगति सॉफ्टवेयर डेवलपमेंट की जटिलता को कम करने, गुणवत्ता सुधारने और डेवलपर्स का समय बचाने की दिशा में बढ़ रही है.
1 टिप्पणियां
Hacker News की राय
यह ट्रेंड दिलचस्प है कि LLM को implementation से पहले test code लिखने में इस्तेमाल करने की कोशिश हो रही है
शायद मैंने TDD बहुत ज़्यादा किया है, इसलिए मुझे लगता है कि tests बताते हैं कि system को कैसे काम करना चाहिए, और यह हिस्सा इंसान को define करना चाहिए। code को tests द्वारा बनाए गए guardrails के अंदर fit होना चाहिए
हालांकि LLM उन areas को पहचानने में मदद कर सकता है जहां specification कमज़ोर है। हो सकता है यहां यही हो रहा हो कि कम specified हिस्सों के लिए unit tests suggest करवाए जा रहे हों
LLM से पहले भी कभी-कभी सोचता था कि अगर सारे tests पहले से लिख दिए जाएं, तो क्या कोई बंदर typewriter से application बना सकता है
ये tests यह define नहीं करते कि इंसान के हिसाब से code को कैसे behave करना चाहिए, बल्कि यह define करते हैं कि मौजूदा codebase असल में कैसे behave करता है
इससे regression को कम रखते हुए rewrite, refactor और redesign किया जा सकता है। बहुत सारे legacy code की समस्या यह होती है कि कोई भी intended behaviour को नहीं समझता, और कभी-कभी users भी मानते हैं कि उसे actual behaviour से अलग तरीके से काम करना चाहिए
इसलिए अगर कोई explicitly desired change नहीं है, तो सबसे महत्वपूर्ण बात है behaviour को न बदलना
basic idea यह है कि पूरी closed-form proof system के बजाय code behaviour के कमजोर propositions को “properties” के रूप में express किया जाए, और मूल रूप से probabilistic limits के भीतर verify किया जाए
classic example string reverse करना है। किसी string को दो बार reverse करने पर आम तौर पर input वापस आना चाहिए। code की एक line से, time और electricity जितनी अनुमति दें, उतने अजीब Unicode edge cases भी check किए जा सकते हैं
example मामूली लग सकता है, लेकिन मैंने देखा है कि CUDA experts, जो automatic differentiation और kernel work कर रहे थे और जो आगे चलकर PyTorch बना, इस तरीके का बेहद अच्छा इस्तेमाल करके आधी मेहनत और cost में code reliability लगभग 5x हासिल कर रहे थे
यह हमेशा सही fit नहीं होता, लेकिन जब fit हो जाए तो शानदार है, और LLM शुरुआत से शुरू करने के बजाय Hypothesis examples के काफी करीब पहुंच सकता है
इसके उलट tests लिखते समय आपको बेहद verbose और constraints से भरी language में explain करना पड़ता है कि application को क्या करना चाहिए, और कुछ glorified if/else डालने के लिए दर्जनों या सैकड़ों lines का setup code लिखना पड़ता है
C++ या Java जैसी languages में unit testing इतनी boring चीज़ों से भरी होती है कि LLM से वह काम करवाने की instinct होना बिल्कुल भी हैरानी की बात नहीं
मैंने कई engineers देखे हैं जो कई दिन code लिखने के बाद मजबूरी में बाद में कुछ tests लिखते हैं ताकि “prove” कर सकें कि system काम करता है। coverage low होती है और आम तौर पर brittle होती है
जो engineer ऐसे सोचता और काम करता है, उसे ऐसा system भगवान की देन जैसा लगेगा
एक manager भी था जिसने tests पहले लिखने को यह कहकर ban कर दिया था कि इससे काम धीमा होता है। शुक्र है मैं contract पर था, इसलिए “मेरे boss से बात करो” कहकर ignore कर सका, लेकिन शायद उसकी सोच भी ऊपर वाले engineers जैसी ही रही होगी
दूसरे तरीके से देखें तो ज्यादातर developers documentation से नफरत करते हैं। अगर कोई AI code से बढ़िया documentation लिख दे, तो उन्हें अच्छा लगेगा। और ऐसे developers के लिए वह documentation ही बढ़िया है जिसे उन्हें खुद नहीं लिखना पड़े
test code को अक्सर low-priority code माना जाता है और ज्यादा junior engineers को सौंप दिया जाता है, जो desired direction के ठीक उलट लगता है
मैं पूरी चीज़ review नहीं करना चाहता, लेकिन एक हिस्सा खास तौर पर बहुत गलत लगता है
मैंने original paper उसके पोस्ट होते ही जल्दी-जल्दी पढ़ा था और अभी बस skim कर रहा हूं, इसलिए मानकर चलें कि मेरी memory धुंधली है
blog ने लिखा कि Meta के TestGen-LLM tests में से ज्यादातर ने सिर्फ 2.5 extra lines cover कीं, लेकिन एक test ने 1326 lines cover कीं, और उस एक test की value “exponentially larger” है, साथ ही LLM के aggressively outside the box सोचकर unexpected edge cases पकड़ने की value बड़ी है
लेकिन “exponentially more valuable” जैसी phrase से ही nonsense detector बज जाना चाहिए। paper देखने पर authors इस 1326-line coverage को jackpot लगने वाला एक single test बताते हैं, और कहते हैं कि एक single TestGen-LLM test से expected realistic extra line coverage median 2.5 lines है
authors “unexpected edge cases” या “thinking outside the box” का जिक्र नहीं करते। बल्कि वे इसे एक exceptional case के रूप में पेश करते हैं, जहां शायद किसी भयानक switch statement की एक branch hit हुई हो, या code coverage calculate करने के तरीके की कोई accident हो सकती है
“qualitative results” section में भी इसका और गहराई से analysis न किया जाना ध्यान खींचता है। inaccurate commentary किसी की मदद नहीं करती। internet पर पहले से ही बहुत लोग हैं जो पढ़ने का नाटक करने के बाद समझने का नाटक करते हैं
मैंने article edit किया है ताकि यह ज्यादा clear हो कि कुछ interpretations मेरी राय हैं
यह article paper summary से ज्यादा paper के results का मतलब क्या है, इस पर commentary है। आखिर Hacker News discussion के लिए ही है
फिर भी “exponentially more valuable” वाला हिस्सा मुझे अब भी सही लगता है। LLM testing coverage के मामले में संयोग से “jackpot” लगा सकता है, यही इसकी value का core है
अलग-अलग combinations लगातार try करते हुए अगर paper जैसा सिर्फ एक jackpot भी मिल जाए, तो team के लिए वह बहुत valuable है। वह ऐसा test हो सकता है जिसे इंसान के लिए सीधे लिखना clear नहीं था या जो बहुत boring था
Big Tech codebases (F/G) में, जहां मुझे यह पता था कि क्या test करना है, लेकिन “कैसे test करना है” यह समझने में बहुत ज्यादा समय लगता था, उस नजरिए से मुझे इसकी value बड़ी लगती है
साफ है कि यह team भी code lines और diff count के आधार पर push कर रही है। आखिर में यह बस एक और code generation tool बनेगा, जो debug करना मुश्किल code का पहाड़ खड़ा करेगा
अच्छे tests लिखना मुश्किल है, और coverage हमेशा अच्छी चीज़ नहीं होती
बहुत ज़्यादा tests लिखकर program को जकड़ देना और असल में उसे बदलाव पहचानने वाला program बना देना आसान है। बात कुछ ऐसी हो जाती है: “आपने कुछ बदला है, सारे tests टूट गए। कोई बात नहीं, अब LLM से फिर generate करवा लेते हैं! 100% coverage! कमाल है! प्रगति है!”
मेरे लिए तो यह जांचने का मौका है कि वह बदलाव इरादतन था या नहीं। उसके बिना आप कैसे जानेंगे कि program वही कर रहा है जो उसे करना चाहिए?
इसके अलावा, आपको बाकी पाँच लोगों के सोचे हुए अच्छे tests पढ़ने पड़ते हैं। हम सभी tests लिखने में अच्छे नहीं हैं; बस हर कोई अपने तरीके से लिखता है
उसके बाद हर बदलाव पर developer स्वाभाविक रूप से regenerate button दबाता और सब कुछ commit कर देता। diff भरपूर होते थे, लेकिन signal संदिग्ध था
semiconductor industry में, खासकर computational lithography में, जहाँ test-driven design standard है, काम करने के बाद यह बात मुझे ठीक से समझ नहीं आती
इसका मतलब यह नहीं कि production code से पहले हमेशा tests लिखने ही चाहिए। लेकिन tests भी codebase के बाकी हिस्सों जितने ही code का हिस्सा हैं, और उन्हें target code के साथ ही लिखा जाना चाहिए
tests का सबसे महत्वपूर्ण हिस्सा developer का intent दिखाना है। test suite दिखाता है कि code का इस्तेमाल कैसे होना चाहिए, वह क्या करता है, क्या नहीं करता, और उसे किसलिए लिखा गया था
तब कोई दूसरा developer जब उस code का इस्तेमाल या modification करे, तो उसे codebase में Sherlock Holmes की तरह clues ढूँढते नहीं फिरना पड़ता
अगर tests कहानी नहीं बताते, तो आप tests गलत तरीके से लिख रहे हैं
जब तक computer दिमाग पढ़कर intent को बेहतर नहीं समझने लगते, AI/LLM-based generator यह काम हमारी जगह नहीं कर सकते
बेशक अगर test suite का एकमात्र लक्ष्य commit से पहले checks में green check mark पाना और शानदार coverage number दिखाना है, तो AI से productivity दोगुनी की जा सकती है
automatic code generator आपको खराब code को रोशनी की गति से और ज़्यादा लिखने में मदद करेगा। अगर कोई शिकायत करे कि boilerplate ज़्यादा होने से code bloated और समझने में मुश्किल है, तो कह दीजिए कि AI से संभाल लें। आपके लिए तो काम कर गया
सच में development का future ऐसा ही दिखता है, लेकिन यह वह future नहीं है जिसकी मैं उम्मीद करता हूँ
आपने जो बताया वह code के “core” को test करने जैसा लगता है। ऐसे tests जो documentation, validation और stability का कुछ हिस्सा भी निभाते हैं
fuzzing जैसे दूसरे tests पूरी तरह अलग value देते हैं। मुझे लगता है AI-based tests distribution की tail side में जगह बना सकते हैं—ऐसे बहुत सारे कम-value tests जिन्हें human energy और time की कमी के कारण छोड़ दिया जाता है
मौजूदा AI tools की स्थिति को भी मैं ऐसे ही देखता हूँ। ये cognitive assistive tools हैं
अगर यह research direction अगले कुछ वर्षों में काफ़ी फलदायी न निकली, तो मुझे उल्टा आश्चर्य होगा
paper खुद posted होने पर मैंने जो लिखा था, उसे थोड़ा edit करके फिर quote कर रहा हूँ। इनके लेख में statistics को गलत तरीके से पेश किया गया है
https://news.ycombinator.com/item?id=39406726
abstract actual paper content से मेल नहीं खाता। summary ऐसे पढ़ी जाती है जैसे test case के आधार पर percentages हों: “75% correctly build हुए, 57% reliably pass हुए, 25% ने coverage बढ़ाई”
actual report test class के आधार पर बात करती है, और हर class में एक या ज़्यादा test cases होते हैं
इसका मतलब है: “75% test classes में कम से कम एक नया test case था जो correctly build हुआ”, “57% test classes में कम से कम एक test case था जो correctly build हुआ और reliably pass हुआ”, और “25% test classes में कम से कम एक ऐसा test case था जो build हुआ, pass हुआ और उसी build target की दूसरी test classes की तुलना में line coverage बढ़ाता था”
ये दोनों पूरी तरह अलग statements हैं। हर test class extension attempt में test case generate करने की कई attempts हो सकती हैं, इसलिए footnote तक है कि per-test-case success rate आम तौर पर per-test-class success rate से बहुत कम होता है
लेकिन conclusion में वे abstract की तरह results को फिर गलत तरीके से पेश करते हैं। वे लिखते हैं कि experimental mode में TestGen-LLM इस्तेमाल करने पर per-test-case success rate 25% था, और line coverage की requirement ढीली करके केवल build और pass मांगें तो success rate 57% हो जाता है
उन लोगों के लिए empathy होती है जिन्हें आगे चलकर इस घटिया LLM legacy code को maintain करना पड़ेगा
यह देखने में बदसूरत होगा
उल्टा, यह काफ़ी मिलता-जुलता दिख सकता है; comments और docs ज़्यादा अच्छे हो सकते हैं, और actively गलत होने की संभावना कम भी हो सकती है
LLMs अभी से कभी बेहतर नहीं होंगे और पिछले 2 सालों में बिल्कुल progress नहीं हुई है। ये बस चमकदार Markov chains हैं
इन्हें code लिखने में केवल वही व्यक्ति इस्तेमाल कर सकता है जिसे coding नहीं आती और जो बिना किसी review के blind तरीके से code production में commit करता है
जिन्हें coding आती है, उनके लिए ये किसी काम के नहीं हो सकते और productivity भी नहीं बढ़ा सकते
यह LLM वाली बकवास, जो दुनिया को बिल्कुल नहीं बदलेगी, मैं ignore करूँगा—और आपको भी ज़रूर करना चाहिए
अगर इसे अच्छी तरह अलग न रखा जाए, तो कोई अनजान manager high coverage की मांग करता है और उत्साही juniors चुपके से बड़ी मात्रा में AI tests डाल देते हैं, जिससे यह आसानी से developers के खिलाफ hostile environment बन जाता है
आखिर में हालत यह हो जाती है कि हर बार काम submit करते समय ऐसे LLM-generated test code से मुहर लगवानी पड़ती है जिसका maintenance मुश्किल है
कुछ tests लिखना तेज़ हो सकता है, लेकिन maintenance तेज़ होगा इसकी कोई गारंटी नहीं। जिस code को test किया जा रहा है, उसके maintenance पर भी यही लागू होता है। क्योंकि अच्छे tests generate होंगे इसकी कोई गारंटी नहीं है
tests लिखते हुए जूझने की प्रक्रिया आम तौर पर developer को design को शुरुआती चरण में check करने में भी मदद करती है। अगर test करना मुश्किल है, तो अक्सर design अच्छा नहीं होता; उदाहरण के लिए, जब दूसरों के साथ मिलकर code लिखना हो, तो component contracts अक्सर पर्याप्त रूप से abstract नहीं किए गए होते
एक बात जो आसानी से छूट जाती है, वह यह है कि tests sacrificial code होते हैं। उनमें से ज्यादातर पूरी उम्र कुछ भी catch नहीं करेंगे, और यह ठीक है। क्योंकि वे automated reassurance देते हैं और failure होने पर गलत संकेतों को कम करते हैं
लेकिन probabilistic safety net में अधिकतम निवेश करने से हमेशा reward नहीं मिलता। coverage शीर्ष के करीब पहुंचती है तो marginal utility घटती जाती है। standard library जैसे high-traffic execution paths न हों, तो high coverage पर गर्व करने का आम तौर पर फायदा नहीं मिलता
इसके अलावा, लगभग हमेशा सिर्फ unit tests नहीं, बल्कि integration tests, system tests आदि वाला पूरा testing ecosystem होना चाहिए ताकि सब कुछ चले। क्या LLM design meetings में बैठकर architecture समझेगा और ऐसे tests भी लिख देगा? या फिर जो कर सकता है उसे बढ़ा-चढ़ाकर दिखाकर जो किया जाना चाहिए उसे पीछे धकेल देगा?
tests में effort लगाते समय, सिर्फ लिखने के समय ही नहीं बल्कि design और maintenance के समय भी “क्या relevant है” यह समझने की समझ चाहिए। इंसान यह काफी अच्छी तरह करते हैं, AI tools नहीं
LLM जहां समय बचा सकता है, वह अनुभवी developer की keystrokes हैं जिसे पहले से अंदाजा है कि क्या test करना अच्छा है और क्या नहीं। साथ ही यह code में कम relevant चीजें चुपके से लाकर बाधा भी बन सकता है, और पहले से बनता रहा है
हम keystrokes पैदा करने वाली economy नहीं चाहते। हम अच्छी तरह सोची-समझी, highly relevant keystrokes का set चाहते हैं। और उम्मीद है कि बाद वाली चीज पहली वाली से अच्छी तरह अलग रहे, ताकि समय के साथ उसकी objective utility या उसकी कमी स्पष्ट हो सके
मैं यह GPT-4 के साथ पहले ही कर चुका हूं
मैंने उसे एक TypeScript module दिखाकर unit tests generate करने को कहा, तो उसने working tests बनाए जो happy path के साथ-साथ कुछ edge cases भी cover करते थे
ChatGPT कई मायनों में उम्मीद से बेहतर करता है। tests GPT की capabilities के हिसाब से आसान लगते हैं
पिछले हफ्ते मैंने उससे AST traverse करके React Flow graph और components बनाने वाला Python code लिखवाया। मैंने कोई edit नहीं किया, बस prompt feedback कुछ बार repeat किया, और वह बहुत अच्छी तरह चला। GPT में मैंने ऐसी कई दिलचस्प क्षमताएं देखी हैं
AI कैसे जानता है कि कौन-से tests लिखने चाहिए?
यह दिलचस्प experiment है, लेकिन थोड़ा संदिग्ध भी। मेरे हिसाब से software development में AI सबसे अच्छी मदद तब कर सकता है जब programmer अपने code या किसी और के code के बारे में सवाल पूछे और AI जवाब दे। कभी-कभी इसमें code suggestions शामिल हो सकते हैं, लेकिन हमेशा जरूरी नहीं
इसे “क्या इस code को simplify करने का कोई तरीका है?”, “कौन-से inputs error पैदा कर सकते हैं?” जैसे सवालों के जवाब दे पाने चाहिए
AI को हमें code समझने और उसे बेहतर करने के तरीके समझने में मदद करनी चाहिए। अगर हम उसे न बताएं कि क्या करना है, तो AI नहीं जान सकता कि हम क्या चाहते हैं, इसलिए उसे सब कुछ खुद से लिखने नहीं देना चाहिए
tests इसका अच्छा उदाहरण हैं। हम क्या test करवाना चाहते हैं?
आखिरकार ऐसा AI code generation आया जो समझ में आता है