LLM-based Mockless Unit Test Generation for Java
यह शोध पत्र MocklessTester को प्रस्तुत करता है, जो मॉकलेस जावा यूनिट टेस्ट जेनरेट करने के लिए एक नवीन LLM-आधारित दृष्टिकोण है, जो भ्रम (hallucination) और निर्भरता संबंधी चुनौतियों से पार पाने के लिए संदर्भ-समृद्ध पीढ़ी (context-enriched generation) और बाधा-प्रवर्तित सुधार (constraint-enforced fixing) को जोड़ता है, जो बेंचमार्क डेटासेट पर कवरेज और म्यूटेशन स्कोर में अत्याधुनिक बेसलाइनों से काफी बेहतर प्रदर्शन करता है।
मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
कल्पना कीजिए कि आप एक कारखाने के गुणवत्ता निरीक्षक (quality inspector) हैं जो जटिल मशीनें बनाता है। आपका काम एक चेकलिस्ट (एक "टेस्ट") लिखना है ताकि यह सुनिश्चित किया जा सके कि मशीन का हर हिस्सा सही ढंग से काम करता है।
सॉफ्टवेयर की दुनिया में, ये मशीनें जावा प्रोग्राम (Java programs) हैं, और ये चेकलिस्ट यूनिट टेस्ट (unit tests) हैं।
पुराना तरीका: "नकली पुर्जों" की समस्या
पारंपरिक रूप से, जब निरीक्षक मशीन के किसी विशिष्ट हिस्से (जैसे कि एक गियर) का परीक्षण करते हैं, तो वे अक्सर वास्तविक इंजन या वास्तविक ईंधन पंप का उपयोग नहीं करते जो उससे जुड़ा होता है। इसके बजाय, वे मॉक्स (mocks) का उपयोग करते हैं—जो उन हिस्सों के नकली, रबर के प्रतिकृति (replicas) होते हैं।
- उपमा (Analogy): कल्पना कीजिए कि कार के इंजन का परीक्षण करने के लिए आप ईंधन पंप के कार्डबोर्ड कटआउट को जोड़ रहे हैं। आप यह तो जांच सकते हैं कि इंजन घूम रहा है या नहीं, लेकिन आप कभी भी यह नहीं जान पाएंगे कि वास्तविक ईंधन पंप जाम है या टूटा हुआ है क्योंकि आपने वास्तव में उसका उपयोग ही नहीं किया।
- समस्या: यह तेज़ और आसान है, लेकिन यह "उथली" (shallow) कवरेज छोड़ देता है। यह उन बग्स को मिस कर देता है जो तब होते हैं जब वास्तविक हिस्से आपस में क्रिया करते हैं।
नई चुनौती: "असली पुर्जों" का दुःस्वप्न
लेखकों ने इन कार्डबोर्ड कटआउट का उपयोग करना बंद करने का निर्णय लिया। वे वास्तविक ईंधन पंपों और इंजनों (वास्तविक डिपेंडेंसीज़) का परीक्षण करना चाहते थे।
- समस्या: यह अविश्वसनीय रूप से कठिन है। यदि आप एक वास्तविक ईंधन पंप जोड़ने का प्रयास करते हैं, तो आपको यह जानना होगा कि उसे ठीक से कैसे जोड़ा जाए, स्विचों को किस क्रम में चालू किया जाए, और किस प्रकार के ईंधन का उपयोग किया जाए।
- AI का संघर्ष: शोधकर्ताओं ने इन टेस्ट को लिखने के लिए एक सुपर-स्मार्ट AI (एक लार्ज लैंग्वेज मॉडल, या LLM) का उपयोग किया। लेकिन AI बार-बार दो प्रकार की गलतियाँ करता रहा:
- "जानने की कमी": AI को यह नहीं पता था कि कारखाने ने वास्तव में इन हिस्सों को कैसे जोड़ा था। उसने अनुमान लगाया, जिससे ऐसे नकली कनेक्शन बन गए जो वास्तविक कोड में मौजूद ही नहीं थे।
- "पालन न करना": भले ही आपने AI को नियम बता दिए हों (जैसे, "इंजन शुरू करने से पहले स्विच चालू करें"), फिर भी वह कभी-कभी उन्हें अनदेखा कर देता था और उन्हें गलत क्रम में करता था, जिससे मशीन फट जाती (क्रैश हो जाती) थी।
समाधान: "MocklessTester" से मिलिए
टीम ने MocklessTester नामक एक नया सिस्टम बनाया है। इसे एक सुपर-नोटबुक वाले मास्टर इंस्पेक्टर के रूप में समझें।
AI को केवल "टेस्ट लिखने" के लिए कहने के बजाय, MocklessTester उसकी गलतियों को सुधारने के लिए उसे दो विशेष उपकरण देता है:
1. "वास्तविक जीवन के उदाहरण" टूल (Context-Enriched Generation)
"जानने की कमी" की समस्या को ठीक करने के लिए, सिस्टम कारखाने के पूरे इतिहास को स्कैन करता है।
- उपमा: ईंधन पंप को कैसे जोड़ा जाए इसका अनुमान लगाने के बजाय, AI कारखाने की लॉगबुक देखता है कि अतीत में अन्य श्रमिकों ने उस पंप को सफलतापूर्वक कैसे जोड़ा था। यह उन वास्तविक, काम करने वाले पैटर्न की नकल करता है।
- परिणाम: AI काल्पनिक कनेक्शन बनाना बंद कर देता है और कोड में पाए जाने वाले वास्तविक कनेक्शनों का उपयोग करने लगता है।
2. "कठोर नियम पुस्तिका" टूल (Constraint-Enforced Fixing)
"पालन न करना" की समस्या को ठीक करने के लिए, सिस्टम एक सख्त सुरक्षा निरीक्षक की तरह कार्य करता है जो दो चरणों में काम की जाँच करता है।
- चरण 1 (ड्राफ्ट): AI एक टेस्ट लिखता है।
- चरण 2 (ऑडिट): टेस्ट स्वीकार किए जाने से पहले, सिस्टम इसकी तीन सख्त नियमों के विरुद्ध जाँच करता है:
- सिंबल चेक (Symbol Check): "क्या आपने कोई ऐसा हिस्सा बना दिया जो अस्तित्व में ही नहीं है?" (यदि हाँ, तो उसे वास्तविक हिस्से से बदलें)।
- प्रोटोकॉल चेक (Protocol Check): "क्या आपने स्विच चालू करने से पहले इंजन शुरू कर दिया?" (यदि हाँ, तो क्रम को ठीक करने के लिए AI को मजबूर करें)।
- मेमोरी चेक (Memory Check): "क्या आपने पहले भी यही सुधार करने की कोशिश की थी और असफल रहे थे?" (यदि हाँ, तो दूसरा दृष्टिकोण अपनाएं)।
- ट्विस्ट: यदि AI ऑडिट में विफल रहता है, तो उसे एक जस्टिफिकेशन (तर्क) लिखना होता है जिसमें यह बताया गया हो कि उसका नया सुधार नियमों का पालन क्यों करता है। यह AI को फिर से कार्य करने से पहले सावधानी से सोचने के लिए मजबूर करता है।
परिणाम: बेहतर टेस्ट, थोड़ा अधिक समय
शोधकर्ताओं ने इस नए सिस्टम का परीक्षण दो सॉफ्टवेयर प्रोजेक्ट्स के सेट पर किया:
- Defects4J: पुराने जावा प्रोजेक्ट्स का एक मानक संग्रह।
- Deps4J: आधुनिक, जटिल प्रोजेक्ट्स का एक बिल्कुल नया संग्रह जिसे AI ने पहले कभी नहीं देखा था (यह सुनिश्चित करने के लिए कि AI केवल पुराने उत्तर याद करके "चीटिंग" नहीं कर रहा है)।
निष्कर्ष:
- गहरी कवरेज (Deeper Coverage): MocklessTester ने पिछले सर्वोत्तम तरीके की तुलना में 20% अधिक बग्स खोजे और 25% अधिक कोड लाइनों को कवर किया। महत्वपूर्ण रूप से, इसने वास्तव में मशीन के वास्तविक जुड़े हुए हिस्सों का परीक्षण किया, न कि केवल अलग किए गए गियर का।
- लागत: इसमें थोड़ा अधिक समय और "दिमागी शक्ति" (कंप्यूटिंग टोकन) लगी। AI को सही होने के लिए कई बार प्रयास करना पड़ा।
- फैसला: अतिरिक्त समय सार्थक था। टेस्ट की गुणवत्ता बहुत अधिक थी, जिसने उन वास्तविक समस्याओं को पकड़ा जिन्हें "नकली भाग" वाले टेस्ट मिस कर देते थे।
संक्षेप में
यह पेपर दिखाता है कि AI को वास्तविक उदाहरण देने से कि कोड का उपयोग कैसे किया जाता है, और उसे कठोर नियमों का पालन करने के लिए मजबूर करने और अपने काम को समझाने का दूसरा मौका देने से, हम अंततः नकली, रबर-स्टैम्प "मॉक" भागों पर निर्भर हुए बिना जटिल सॉफ़्टवेयर का परीक्षण स्वचालित कर सकते हैं। यह एक कार का परीक्षण कार्डबोर्ड इंजन के साथ करने बनाम वास्तविक चीज़ के साथ करने के बीच का अंतर है।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।