सुलझाने जावा classpath नरक

Question

मान लीजिए मैं एक विरासत JUnit टेस्ट स्वीट निम्नलिखित परीक्षण भी शामिल है:

public class AwesomeTest { 
    public void testBusinessLogic() { 
    ... 
    [awesome mocking library] 
    ... 
    } 
} 

public class AmazingTest { 
    public void testBusinessProcess() { 
    ... 
    [amazing xml operation] 
    ... 
    } 
} 

अब लगता है कि बहुत बढ़िया मजाक पुस्तकालय बहुत बढ़िया BCEL बाईटकोड पीढ़ी पुस्तकालय पर निर्भर करता है कि किस वर्ग में शामिल है org.useful.XMLClass और इस लाइब्रेरी में XMLClass का संस्करण 1 है।

अब मान लें कि अमेज़िंग एक्सएमएल ऑपरेशन अमेज़िंग एक्सएमएल लाइब्रेरी पर निर्भर करता है जिसमें कक्षा org.useful.XMLClass है और इस पुस्तकालय में एक्सएमएल क्लास का संस्करण 2 है।

यह भी मान लें कि कक्षा का संस्करण 2 संस्करण 1 के साथ संगत नहीं है - इसलिए क्लासपाथ में संस्करण की उच्च प्राथमिकता है - यह दूसरे संस्करण की निर्भरताओं को तोड़ देती है।

यह भी मान लें कि 400 परीक्षण हैं जो भयानक मॉकिंग लाइब्रेरी पर भरोसा करते हैं - इसलिए पुनर्लेखन एक वांछनीय विकल्प नहीं है।

यह भी मान लें कि कुछ महत्वपूर्ण व्यावसायिक सुविधाएं अद्भुत xml libary के साथ बनाई गई हैं - और इसे दृढ़ता से प्राथमिकता दी जाती है कि इसे फिर से लिखना न पड़े।

आप इस क्लासपाथ नरक स्थिति को कैसे हल करते हैं - एंटी टेस्ट चलाने के अलावा (मान लीजिए कि आप उन्हें एंट के साथ चला रहे हैं) दो अलग-अलग मैन्युअल रूप से ऑर्डर किए गए क्लासपाथ और मैन्युअल रूप से निर्धारित परीक्षण उप-सेट के साथ दो बार? (मैं कस्टम क्लासलोडर्स के साथ एक विचार के लिए खुला हूं - लेकिन यह एंटी सॉल्यूशन के साथ दोहरी कस्टम क्लासपाथ के समान रखरखाव के समान स्तर के बारे में लगता है)

Answer 1

मुझे विश्वास है कि एक जावा एजेंट और कस्टम क्लास का उपयोग करके एक काफी पारदर्शी समाधान संभव है लोडर। विचार निम्न है:

1. Instrumentation Framework (जावा एजेंट) का उपयोग कक्षाओं को लोड होने पर रोकने के लिए करें। जब आप विस्मयकारी मॉकिंग लाइब्रेरी में एक क्लास का पता लगाते हैं, तो org.useful.XMLClass पर सभी संदर्भों को प्रतिस्थापित करें, उदाहरण के लिए, intercepted.org.useful.XMLClass।
2. कस्टम क्लास लोडर बनाएं, जिसमें आप जांचते हैं कि अनुरोधित वर्ग intercepted.org.useful.XMLClass है या नहीं। यदि ऐसा है, तो XMLClass का संस्करण लोड करें जिसका उपयोग मॉकिंग लाइब्रेरी द्वारा किया जाता है। अन्य सभी अनुरोध डिफ़ॉल्ट रूप से संभाले जा सकते हैं।

कस्टम क्लास लोडर का उपयोग करें और परीक्षण चलाने के दौरान जावा एजेंट को संलग्न करें, और सब कुछ ठीक से चलना चाहिए, जैसे कि कोई निर्भरता संघर्ष नहीं है।

Answer 2

मुझे लगता है कि स्टीवन के जवाब महान है - पूर्णता के लिए के लिए और क्योंकि इस सवाल इतने सारे मत मिले - मैं सभी विकल्पों के बारे में सोचा हम (बुरा भी शामिल होते हैं)

1. विभाजन परीक्षण साझा करना चाहते थे (या कुछ परीक्षण) एक अलग क्लासपाथ ऑर्डर (नुकसान - आपको अपने परीक्षणों के साथ अन्य महत्वपूर्ण मुद्दों को याद करने का कारण बन सकता है - एक व्यावहारिक विकल्प नहीं)
2. अमेज़िंग एक्सएमएल ऑपरेशन रोल करें और एक और तरीका लागू करें (निवेश दिया गया है इसके उपयोग में, और तथ्य यह है कि अन्य परिचालन समाप्त हो गए थे - इसे खारिज कर दिया गया था)
3. एक नई मॉकिंग लाइब्रेरी का उपयोग करके परीक्षणों को दोबारा लिखें (यह लंबी अवधि में अच्छा है - अल्प अवधि में यह हमारे वर्तमान प्रोजेक्ट से बड़ा काम करता है, क्योंकि सैकड़ों और सैकड़ों हैं)
4. का एक अनुकूलित संस्करण बनाएं अद्भुत मॉकिंग लाइब्रेरी जो org.useful.XMLClass के नए संस्करण का उपयोग करती है (यह हमारी वर्तमान प्रोजेक्ट से बड़ी हो गई है)
5. स्रोत से अपमानजनक वर्ग निकालें, और पुराने संस्करण को स्रोत लाइब्रेथ पर स्रोत लाइब्रेरी को ओवरराइड करना (यह चालू यह कई अन्य वर्गों के साथ उलझ गया था - इसलिए यह गैर-तुच्छ था)
6. ऊपर स्टीवन के शानदार विचार का उपयोग करें - फिर यह गैर-तुच्छ
हो गया
7. @ इग्नोर के साथ परीक्षण सेट करें - और भविष्य में प्रोजेक्ट पर पुनः लिखने के लिए उन्हें कतार में रखें।