मैं केवल स्रोत फ़ाइलों के लिए यूनिट परीक्षण कैसे चला सकता हूं?

Question

क्या कोई तरीका है कि मैं जावा क्लास के निर्माण के लिए यूनिट परीक्षण चलाने के लिए चींटी प्राप्त कर सकता हूं? उदाहरण के लिए, यदि MyClass.java पुराना है, तो चींटी MyClass.class का निर्माण करेगी। इसके बाद मैं चाहता हूं कि यह MyClassTest और MyClassTestSuite को भी चलाए, यदि वे मौजूद हैं। इसे नामकरण सम्मेलन पर आधारित नहीं होना चाहिए। मैं एनोटेशन या काम करने वाली किसी अन्य विधि का उपयोग करने के साथ ठीक हूं।

संपादित करें: कई लोगों ने यह कहकर चिंतित किया है कि यह एक बुरा विचार है। यह होगा, अगर मैंने हमारे सभी यूनिट परीक्षणों को चलाने के बिना जांच करने की योजना बनाई है। मेरी मुख्य परियोजना में 16k यूनिट परीक्षण हैं जो चलाने में लगभग 20 मिनट लगते हैं। मैं चेक-इन से पहले उन्हें सब कुछ चलाऊंगा, लेकिन हर बार जब मैं एक फ़ाइल बदलता हूं तो पूरे सूट को चलाने के लिए यह पूरी तरह अव्यवहारिक है। क्षमा करें, मुझे और संदर्भ देना चाहिए था।

Answer 1

यह इतना आसान नहीं है ...

Atlassian Clover पर एक नजर डालें। इसमें वह सुविधा है जिसके बारे में आप सपने देखते हैं, लेकिन यह मुफ़्त नहीं है।

Answer 2

मैं इस दृष्टिकोण की अनुशंसा नहीं करता, साइड इफेक्ट्स द्वारा शुरू की गई त्रुटियों को याद करने का एक अच्छा मौका है।

Infinitest Website

अवलोकन के लिए स्क्रीनकास्ट यहाँ देखें::

Answer 3

Infinitest पर एक नजर डालें, तो यह ग्रहण (और Intellij) कि स्रोत फ़ाइलों के आधार पर परीक्षण चलाता है के लिए एक प्लगइन आप बस बदल गया है है

Screencast Overview

Answer 4

यह मेरे लिए एक बुरा विचार लगता है। निश्चित रूप से बदली गई स्रोत फ़ाइलों को परीक्षण की आवश्यकता है, लेकिन उन फ़ाइलों पर निर्भर किसी भी फाइल, और जो भी उन पर निर्भर करता है, आदि। आपको यह ट्रैक करना होगा कि कौन सी फाइल अन्य फाइलों पर निर्भर करती है, और यह हल करने की एक बड़ी समस्या है।

मेरी राय में, यदि परियोजना इतनी बड़ी है कि परीक्षण के निर्भरता पेड़ को हल करने की कोशिश में महत्वपूर्ण लाभ है, तो शायद परियोजना बहुत बड़ी है? हो सकता है कि इसे अलग-अलग परियोजनाओं में विभाजित करने का समय हो जो एक साथ काम करते हैं, जिसे प्रत्येक एक दूसरे से अलग किया जा सकता है।

Answer 5

मैं उन अन्य लोगों के साथ झुकाव करना चाहता हूं जिन्होंने कहा है कि यह ऐसा कुछ है जिसे आप टालना चाहते हैं। बदले गए विशिष्ट वर्गों के लिए केवल परीक्षण मामलों को चलाने से जोखिम उत्पन्न होता है कि आप एक ऐसा परिवर्तन करेंगे जो एक वर्ग के लिए एक परीक्षा को तोड़ देगा जो बदले नहीं गए थे लेकिन कुछ कोडों पर निर्भरता है।

यह एक जोखिम है भले ही आप एक इंटरफेस में प्रोग्रामिंग के बारे में आक्रामक हैं और यूनिट परीक्षणों में निर्भरता का मज़ाक उड़ाते हैं। उदाहरण के लिए, स्थैतिक उपयोगिता कक्षाओं में सीधे उनका उपयोग करके बहुत से वर्ग होने की संभावना है। यहां, एक ऐसे मामले की कल्पना करना आसान होगा जहां आप स्थिर उपयोगिता पद्धति में बदलाव कर सकें, सुनिश्चित करें कि उस विधि के परीक्षणों ने काम किया है, और कोड के एक टन को तोड़ दिया है, यदि आपने अपना सभी नहीं चलाया है परीक्षण।

Answer 6

एएनटी के साथ ऐसा करने का कोई तरीका नहीं है, लेकिन आप ग्रहण में ऐसा कुछ कर सकते हैं।

केंट बेक ने एक यूक्लीप्स प्लगइन लिखा है जिसे जुनीट मैक्स कहा जाता है जो आपके कोड को सहेजने के बाद आपके यूनिट परीक्षण चलाता है। यह पहले "असफल होने की संभावना" परीक्षण चलाता है।

JUnit Max

Answer 7

ठीक है, तो आप शायद यह वैरिएबल का उपयोग कर, यदि आप एक नामकरण परंपरा का पालन कर सकता है। बदली गई फ़ाइलों की एक सूची प्राप्त करें, और संबंधित परीक्षण चलाएं। लेकिन मैं इसके खिलाफ अनुशंसा करता हूं, जैसे अन्य उत्तरों की व्याख्या।