एक परियोजना में मैं काम कर रहा हूं, जो वसंत का उपयोग कर रहा है, मुझे कुछ ऐसा लगता है जो वास्तव में मेरे दिमाग को चकमा देता है। जाहिरा तौर पर वहाँ इकाई परीक्षण है कि सेम की जरूरत है काम करने के लिए कर रहे हैं और उन सेम एक्सएमएल फाइल से बनाई गई हैं, जैसी चीजों युक्तजावा: क्या एक्सएमएल में सेम को परिभाषित करना अच्छा अभ्यास है?
<bean class="...ListDTO">
<constructor-arg>
<map>
<entry key="use1key">
<value>use1value</value>
</entry>
<entry key="use2key">
<value>use2value</value>
</entry>
</map>
</constructor-arg>
<constructor-arg>
<map>
<entry key="nature1key">
<value>nature1value</value>
</entry>
<entry key="nature2key">
<value>nature2value</value>
</entry>
</map>
</constructor-arg>
<constructor-arg>
<value>false</value>
</constructor-arg>
</bean>
और क्या हुआ? कक्षा के निर्माता ... ListDTO बदल गया और इसलिए बीन स्पष्ट रूप से इस (बहुत verbose IMHO) एक्सएमएल से नहीं बनाया जा सकता है।
क्या कोई मुझे बता सकता है कि यह क्यों अच्छा अभ्यास है (क्या वास्तव में?) जावा कोड के बजाय एक्सएमएल में ऐसी चीज डालने के लिए? यदि यह जावा कोड में था, जैसे ही ... ListDTO बदल गया होगा, यूनिट टेस्ट संकलित करने से इनकार कर दिया होगा (भले ही यूनिट टेस्ट का हिस्सा तुरंत चालू हो जाए कि बीन निष्पादित नहीं हुआ [किसी भी कारण से])।
बोनस प्रश्न: क्या सभी यूनिट परीक्षणों को चलाने के अलावा इन सभी टूटा "एक्सएमएल में बीन्स" आसानी से ढूंढने का कोई तरीका है, देखें कि कौन से लोग असफल हो रहे हैं और फिर कुल्ला और दोहराना चाहते हैं?
मेरे लिए यह एक बहुत ही गंभीर मुद्दा है कि आप एक कन्स्ट्रक्टर बदल सकते हैं और आईडीई कार्य करेगा जैसे सब कुछ ठीक था: इसके लिए औचित्य क्या है? (*)
(*) और लेखन: <निर्माता-आर्ग> झूठी 'झूठा के लिए 'मुझे एक अच्छा औचित्य नहीं दिखता है ... –
Gugussee