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 की रायें

  • पहले जिस बड़ी insurance company में काम किया था, वहाँ management ने पूरे codebase के लिए 80% test coverage का लक्ष्य तय कर दिया। नतीजा यह हुआ कि लोग लक्ष्य पूरा करने के लिए Java DTO के getter/setter पर बेकार unit tests लिखने लगे
    जाहिर है, developers Sonar के coverage measurement rules भी नहीं बदल सकते थे, और junior developer रहते हुए मैंने सीखा कि सिर्फ KPI देखने से ऐसी हरकतें incentivize हो सकती हैं जो मूल इरादे से मेल नहीं खातीं
    अच्छी तरह design किए गए कुछ E2E test scenarios शायद software quality के लिए बेहतर होते

    • एक मिलते-जुलते codebase में inexperienced developers द्वारा बनाए गए careless logic को काफी simplify करके मैंने एक PR निकाला, जिसने codebase को 20% घटा दिया, और tests व user requirements दोनों pass कर गए
      समस्या यह थी कि पुराना messy code 95% coverage के साथ बहुत अच्छे से tested था। नया code 100% coverage वाला था, लेकिन काफी छोटा हो जाने के कारण overall coverage उल्टा घट गया और वह pass नहीं हुआ
      बचा हुआ code सिर्फ Swing UI code था, जिसे test करना मुश्किल था और tests का मतलब भी बहुत कम था, इसलिए dev lead ने Swing tests लिखने में 1–2 हफ्ते लगाने के बजाय पुराने code को repository में कहीं छोड़ दिया और tests को बस उसी code की ओर point करा दिया
      आखिरकार production में कभी call न होने वाली dead code की हजारों lines Sonar को satisfy करने के लिए repository में रह गईं
    • मेरी पहली internship में भी management ने code quality tool जबरन introduce किया था, और उसमें “magic numbers disable” rule था
      नतीजा यह हुआ कि headers में static const unsigned ONE = 1;, TWO = 2;, THREE = 3; जैसे constants हजारों की संख्या तक बन गए
    • इसका समाधान मुझे mutation testing लगता है। यह सिर्फ code execute करके coverage को धोखा देने की बात नहीं है, बल्कि tests को actual implementation verify करने के लिए मजबूर करता है
      https://en.m.wikipedia.org/wiki/Mutation_testing
      लगभग हर language में tools और frameworks हैं; उदाहरण के लिए stryker-mutator(C#, TypeScript), pitest(Java), mutatest(Python)
    • हमारे यहाँ भी mandatory Sonar scans थे, और जब मैं join हुआ तो tech lead ने “A” grade पर गर्व करते हुए कहा कि “हमारे पास maintain करने के लिए high standards हैं”
      6 साल के career में मैंने इतना खराब application पहली बार देखा था; सिर्फ style ही नहीं, बल्कि वास्तव में पूरी तरह broken हिस्से भी बहुत थे, और किसी को पता नहीं था कि गलत क्या है
      मुझे Sonar सच में बहुत नापसंद है। इसे सिर्फ vulnerabilities report करने के लिए इस्तेमाल करना चाहिए; variable names बदलने या “इस code duplication को refactor करना चाहिए” जैसी बातें नहीं कहनी चाहिए। हमारे पास पहले से Jira ticket backlog है, इसलिए क्या और कब करना है, यह भी निर्देश न दे
      लेकिन managers को ऐसे authority-play tools बहुत पसंद आते हैं
    • “जिस क्षण कोई metric लक्ष्य बन जाती है, वह अच्छी metric नहीं रह जाती” — यह बात बिल्कुल सही बैठती है
      बड़ी समस्या यह है कि उसे mandatory बना दिया जाता है, और फिर मूर्खता से बचने के लिए एक विशाल bureaucratic process से गुजरना पड़ता है। पिछले हफ्ते भी mandatory code quality tool ने शिकायत की कि res.status(200).json() में HSTS header नहीं है, और मुझे उससे लड़ना पड़ा
      manually set करने पर भी, app.use(helmet()) इस्तेमाल करने पर भी वह शिकायत करता रहा, और अंत में ऐसा लगा मानो वह चाहता हो कि पूरा backend एक ही file में लिखा जाए। जबकि HSTS ingress या load balancer पर ज्यादा elegant और automatic तरीके से handle होता है
      मैं इसे false positive mark करके upper management को HSTS क्या है समझाकर approval लेने में 1–2 हफ्ते लगा सकता था, लेकिन आखिरकार मैंने response object prototype में res.sendJson(data, status = 200) जोड़ दिया। यह निश्चित रूप से बेवकूफाना implementation है, लेकिन इससे एहसास हुआ कि heavy bureaucracy वाले क्षेत्रों में खराब software ऐसी ही खराब implementations के योग से बनता है

  • “TestGen-LLM टेस्ट केसों में से 75% सही तरह से build हुए, 57% स्थिर रूप से pass हुए, और 25% ने coverage बढ़ाई” वाला हिस्सा देखें, तो समस्या यह लगती है कि LLM-generated tests के bug वाले behavior को “मंजूरी” दे देने की संभावना काफी ज्यादा है
    खासकर अगर codebase में पहले से ही test coverage कम है, तो शायद ऐसा और भी ज्यादा होगा। जब कोई इंसान खुद नया test लिखता है, तो यह फायदा होता है कि कोई यह तय करने वाला मौजूद होता है कि system बेवकूफ है या test गलत है
    कम-से-कम ऐसे tests को किसी खास test folder में अलग रखना चाहिए और उन्हें उचित स्तर के संदेह के साथ देखना चाहिए

    • Test लिखना सच में bugs खोजने का अच्छा मौका होता है
      हालांकि अच्छे coverage वाला codebase बड़े refactoring को regression के बिना सुरक्षित तरीके से करने देता है, और अगर कोई bug मौजूद है तथा refactoring उस bug को जस-का-तस बचाए रखती है, तब भी यह एक उपयोगी गुण है
      मौजूदा behavior को encode करने के लिए design किए गए test-generation tool का खतरा यह है कि असल में उसने सिर्फ मौजूदा behavior encode किया होता है, लेकिन हमें झूठी सुरक्षा-भावना हो सकती है
      शायद ऐसे को “test” न कहकर “behavior snapshot” जैसा नाम देने से समस्या हल हो सकती है। नाम में यह अर्थ होना चाहिए कि यह सही behavior नहीं, बल्कि मौजूदा behavior capture करता है
    • मुझे लगता है यह ज्यादा सामान्य अनचाहे बदलाव की समस्या का एक उदाहरण है। जब आपके पास ऐसा automation system हो जो खुद को बदल सकता है, तो आप कैसे जानेंगे कि कौन-सा बदलाव सच में intended और सही बदलाव है, और कौन-सा bug, failure या automation की अधूरी जानकारी से निकला symptom है
      इसलिए कौन-सा scenario हुआ है, यह तय करने के लिए कुछ हद तक human supervision हमेशा जरूरी लगता है
      ऐसी चीजें हर तरह के systems में होती हैं, और लोग अक्सर सोचते हैं कि इस मामले की तरह automation की एक और layer चढ़ा देने से यह हल हो जाएगा। Tests मूल रूप से यह verify करने के लिए बनाए गए थे कि program सही चल रहा है या नहीं, लेकिन अगर उसे भी automate कर दें, तो वही समस्या बड़े code में, यानी assertions की जगह tests के रूप में, फिर सामने आती है
    • उल्टा, ऐसे codebase में जहां test coverage कम है और engineers का average tenure लगभग 1 साल है, शुरुआती test skeleton setup करना ही बड़ी बाधा बन जाता है
      हो सकता है आपको test के लिए जरूरी auxiliary inputs के लिए factories बनानी न आती हों, लेकिन यह पता हो कि code खुद कैसे behave करना चाहिए
      अगर LLM test skeleton तैयार कर दे और developer को business logic validation आसानी से लिखने दे, तो यह बड़ा फायदा हो सकता है
      हालांकि अगर generated tests ज्यादातर unit tests की तरह implementation से जरूरत से ज्यादा coupled हैं, तो वे development speed धीमी करेंगे। अगर individual tests को ठीक करना बहुत मुश्किल हुआ, तो बड़े changes में लोग सारे tests delete करके फिर से generate करते दिख सकते हैं
    • पर्याप्त बड़े systems में, behavior bug वाला हो तब भी सिर्फ changed behavior detect करने वाले tests की भी value होती है
      Code का कोई हिस्सा उस bug पर निर्भर हो सकता है, और उसे गलती से या जानबूझकर ठीक करने से ज्यादा गंभीर समस्या पैदा हो सकती है
      बेशक ऐसे tests वास्तविक requirements verify करने वाले tests की जगह नहीं ले सकते
    • नए project या active development वाले project में test auto-generation शायद बुरा idea है, इस पर मैं सहमत हूं
      लेकिन कम coverage के साथ maintenance mode में जा चुके legacy systems अनगिनत हैं, और ऐसे मामलों में मौजूदा behavior verify करने वाले tests generate करना बहुत उपयोगी है। इससे किसी के बदलाव करने पर यह check किया जा सकता है कि बाकी सब वैसा ही है या नहीं

  • PDF पढ़कर लगा कि यह “सिर्फ” ऐसे tests generate करने जैसा है जो बार-बार pass होते हैं, यानी flaky नहीं हैं
    मुख्य उद्देश्य existing code के behavior को freeze करने वाले tests से regression test suite बनाना है, न कि functional requirements जानकर लिखे जाने वाले developer tests को replace करना
    करीब 20 साल पहले जिस company में मैं काम करता था, वहां भी हमने AgitarOne आजमाया था; उसका promise था कि वह Java code के behavior को explore करने वाले test cases automatically generate करेगा। साथ ही pass होने वाले tests लगभग automatic तरीके से बनाकर regression test suite की तरह इस्तेमाल किए जा सकते थे
    व्यक्तिगत रूप से मुझे यह पसंद नहीं आया। बहुत ज्यादा चीजें बन गईं, और management ने coverage बढ़ने को quality बढ़ने के बराबर समझ लिया। यहां FB जिस LLM approach की बात कर रहा है, वह उस समय की तुलना में कितनी बेहतर है, यह जानने की उत्सुकता है
    http://www.agitar.com/solutions/products/agitarone.html

    • इस तरह generate किए गए बहुत-से unit tests regression tests से ज्यादा change detectors बन जाते हैं। Code बदलने पर fail होने वाले test और bug फिर से introduce होने पर fail होने वाले test में बड़ा फर्क है
      जब तक LLM किसी assumption कि अच्छे tests pass होते हैं या oracle पर निर्भर हुए बिना वास्तविक correctness judge नहीं कर पाता, तब तक यहां तक पहुंचना मुश्किल लगता है। Prompt में किसी-न-किसी तरह behavior expectations शामिल करनी होंगी
    • यह system को accidental behavior से बांध भी सकता है
      Test की value इसमें है कि वह यह ensure करे कि किसी की परवाह वाली चीजें न टूटें, न कि किसी specific implementation की उपज भर रहे लगभग कभी इस्तेमाल न होने वाले हर edge-case behavior को हमेशा के लिए freeze कर दे

  • अनुभव के आधार पर, tests लिखना आम तौर पर code quality judge करने का बेहतरीन तरीका है
    अगर tests complex हैं या coverage हासिल करना मुश्किल है, तो संभावना ज्यादा है कि जिस code को test किया जा रहा है, उसे बेहतर करने की जरूरत है

    • Code की testability सच में code quality का अच्छा benchmark है। जो चीजें code को test करना मुश्किल बनाती हैं, वे आम तौर पर low-quality code से जुड़ी होती हैं
      Low coupling, high cohesion और low complexity वाला code unit test करना आसान होना चाहिए

  • कहा गया है कि Instagram के Reels और Stories product evaluation में TestGen-LLM test cases में से 75% सही तरह build हुए, 57% स्थिर रूप से pass हुए, और 25% ने coverage बढ़ाई
    Meta के Instagram और Facebook test events में, applied कुल classes में से 11.5% को improve किया गया, और recommendations में से 73% को Meta software engineers ने production deployment के लिए approve किया
    मुझे नहीं पता यह अच्छा ratio है या नहीं। यह और पढ़ना होगा कि जो चीजें accept नहीं की जा सकीं, वे code review में पकड़ी जाने वाली छोटी-मोटी गलतियां थीं या गंभीर problems। 25% failure rate वाला human engineer, failure types के आधार पर, शायद बहुत मददगार न हो
    Android code के लिए unit test generation automate करने का पूरा mission भी अच्छा direction है या नहीं, इस पर शक है। TDD वाले लोग कब्र में, या शायद घर के बिस्तर में, करवटें बदल रहे होंगे। फिर भी लगता है उन्होंने पीछे कोई caveat जरूर लगाया होगा

    • Facebook में बिना tests वाला काफी code है, और ऐसी चीजें ठीक करने पर किसी को PSC points नहीं मिलते

  • unlogged.io में कुछ समय तक मुख्य फोकस JUnit टेस्ट का auto-generation था, लेकिन कुछ वजहों से वह ठीक से traction नहीं पकड़ सका
    generated test code बहुत ज़्यादा था, इसलिए developers उसे maintain नहीं करना चाहते थे; वह वास्तविक scenarios को simulate नहीं कर पाता था; और code coverage एक vanity metric था। Developers ने बेमतलब scenarios से target पूरा करने के workaround ढूंढ लिए थे
    अब हम सभी unique production scenarios को simulate करने और developer को external dependencies mock करके local पर replay करने योग्य no-code replay tests देने पर काम कर रहे हैं
    संदर्भ के लिए, मैं unlogged.io का founder हूँ

  • मैं उल्टी दिशा में जाना चाहता हूँ। acceptance criteria input करने पर उन्हें verify करने वाले tests generate हों, और फिर उन tests को pass करने वाला code generate हो—ऐसा चाहता हूँ
    Copilot के साथ सीमित रूप से कभी-कभी ऐसा मिलताजुलता किया जा सकता है, लेकिन पता नहीं क्यों लगता है कि कोई भी इस order पर focus नहीं कर रहा

  • TestGen-LLM सच में अजीब outcome है। refactoring या rewrite के पहले step के रूप में शायद काम आ सकता है, लेकिन paper में code coverage पर जोर देना पूरी तरह खराब judgement जैसा लगता है
    अगर कोई organization पहले से high coverage की demand करके बिगड़ चुकी है तो यह अच्छा हो सकता है, लेकिन TestGen-LLM project code को किसी भी तरह बेहतर नहीं बनाएगा और वास्तविक improvements implement करने में friction ही बढ़ाएगा
    pass हो भी सकने और न भी हो सकने वाले edge-case tests generate करना कहीं ज़्यादा उपयोगी होता, लेकिन TestGen-LLM compile errors और failing tests के जरिए LLM garbage को छांटने पर निर्भर करता है
    paper में generated tests के examples बिल्कुल न होने को देखकर शक होता है कि यह भी अब तक देखे गए दूसरे LLM-generated code की तरह amateurish ही होगा

    • हाल ही में मुझे एक ऐसे project को refactor करना पड़ा जिसमें tests बिल्कुल नहीं थे, और LLM द्वारा test drafts auto-generate करना बहुत मददगार रहा
      यहाँ तक कि इससे यह समझने में भी मदद मिली कि code करना क्या चाह रहा था

  • यह दिलचस्प है कि Meta employees ने developers के लिए AI promote करने के मकसद से 12-page paper लिखा, और Sankey diagram तक इस्तेमाल कर लिया
    मैं गलत हो सकता हूँ, लेकिन अगर इस तरह present कर रहे हैं तो reproducible information भी देनी चाहिए, ऐसा लगता है
    यह कोई conspiracy theory नहीं है, बस मेरे पास Meta द्वारा training में इस्तेमाल किए जाने वाले level का data नहीं है। जानना चाहूँगा कि क्या उन्होंने कुछ publish किया है

    • अगर Google जैसा है, तो यह internal infra और monorepo से इतना गहराई से जुड़ा होगा कि publish करना मुश्किल होगा
    • अगर यह FSE 2024 paper है, तो artifact में theory या formal evaluation की जरूरत होनी चाहिए

  • आगे चलकर auto-generated tests के इतने बड़े corpus को maintain करने की cost कितनी होगी, यह जानने की उत्सुकता है
    सिर्फ test cases generate करना ही नहीं, उन्हें update करने का automated तरीका भी provide करना होगा