Java:在XML中定义bean是一种好习惯吗?

Gug*_*see 5 java xml unit-testing javabeans

在我正在开发的一个项目中,使用Spring,我看到了一些令人难以理解的东西.显然,有些单元测试需要bean才能工作,而这些bean是从XML文件创建的,包含以下内容:

<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>
Run Code Online (Sandbox Code Playgroud)

那发生了什么?类的构造函数... ListDTO已更改,因此显然无法从此(非常详细的IMHO)XML创建bean.

有人可以解释一下,为什么将这样的东西放在XML而不是Java代码中是一种好的做法(它真的吗?)?如果是在Java代码中,只要... ListDTO改变了单元测试就会拒绝编译(即使实例化那个bean的单元测试部分没有被执行[无论出于何种原因]).

额外的问题:除了运行所有的单元测试之外,还有一种方法可以在一个项目中轻松找到所有这些破碎的"XML中的bean",查看哪些是失败的,然后进行冲洗和重复?

对我来说,似乎是一个非常严重的问题,你可以改变一个构造函数,并且IDE会表现得好像一切都很好:这有什么理由呢?(*)

Mic*_*rdt 6

这背后的想法是在中央XML配置文件中保留环境(开发,测试,生产)之间的差异,并通过使用不同的配置文件切换环境.

但是,使用bean配置来定义复杂的测试数据结构绝对不是一个好习惯.有人可能会在新注入依赖注入的同时做到这一点,因为它是可能的.