Java: ¿es una buena práctica definir beans en XML?

Question

En un proyecto en el que estoy trabajando, que está usando Spring, veo algo que realmente me deja boquiabierto. Al parecer, hay pruebas de unidad que necesitan los granos a trabajar y los granos se crean a partir de archivos XML, que contiene cosas como:

<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> 

Y qué fue así? El constructor de la clase ... ListDTO cambió y, por lo tanto, el bean aparentemente ya no puede crearse a partir de este (muy detallado en mi humilde opinión) XML.

¿Puede alguien explicarme por qué es una buena práctica (¿es realmente?) Poner tal cosa en un código XML en lugar de Java? Si estuviera en código Java, tan pronto como el ... ListDTO hubiera cambiado, la prueba unitaria se habría negado a compilar (incluso si la parte de la prueba de la unidad instanciando ese bean no se ejecutó [por alguna razón]).

Pregunta extra: ¿hay alguna manera de encontrar fácilmente todos estos "beans en XML" rotos en un proyecto además de ejecutar todas las pruebas unitarias, ver cuáles están fallando y luego enjuagar y repetir?

Para mí, parece un problema bastante serio que puede cambiar un constructor y que el IDE actuaría como si todo estuviera bien: ¿cuál es la justificación para esto? (*) Pregunta

Answer 1

La idea detrás de esto es que mantenga las cosas que difieren entre entornos (desarrollo, pruebas, producción) en un archivo de configuración XML central, y al usar un archivo de configuración diferente, cambia de entorno.

Sin embargo, definitivamente no es una buena práctica usar la configuración de bean para definir estructuras de datos de prueba complejas. Alguien probablemente hizo eso mientras estaba enamorado de la inyección de dependencia, solo porque es posible.

Answer 2

Bono: ¿hay una manera de encontrar fácilmente todos estos "granos en XML" rotas en un proyecto además de correr todas las pruebas unitarias, ver cuáles están fallando y luego enjuague-y-repetición?

Spring Tool Suite o el complemento de Spring para Eclipse puede comprobar que un archivo de configuración de primavera es correcto (tiene todos los parámetros de constructor y no utiliza setters desconocidos).

Answer 3

Creo que debería usar las herramientas SpringSource cuando trabaje con Spring. Puede descargarlo ya sea de forma autónoma o como plugins de Eclipse:

http://www.springsource.com/developer/sts

http://dist.springsource.com/milestone/TOOLS/update/e3.6