2012-05-22 18 views
5

Estoy configurando algunos andamios de prueba alrededor de un proyecto existente. Esto incluye algunas pruebas de integración, utilizando JUnit y DbUnit. También configuré una instalación de Jenkins para una integración continua.JUnit + DbUnit: cambiar la conexión de la base de datos entre entornos de desarrollo y prueba

Mi problema consiste en cambiar las conexiones de base de datos entre los entornos de desarrollo y prueba. Tengo mi propia pila de productos instalada localmente para realizar pruebas e investigaciones rápidas y ad-hoc. A medida que desarrollo, realizo pruebas en mi base de datos privada, ya que es más rápido y no arruinaré el día de nadie con el código de trabajo en progreso.

Una vez que el código esté registrado, Jenkins ejecutará mis pruebas. En este momento todavía está apuntando a mi db local. Prefiero que Jenkins ejecute pruebas en una base de datos diferente, una que se encuentre en el entorno de prueba.

¿Existe una mejor práctica/estrategia/tecnología/etc. para cambiar las conexiones de la base de datos para pruebas sin tener que cambiar el código? Puntos de bonificación si la solución permite a Jenkins realizar las mismas pruebas contra múltiples DB (debería ser posible ya que DbUnit es independiente).


Edits para más información:

El producto es una grande, con de diferentes componentes que interactúan docenas (generalmente en VMS/procesos separados). En un sistema en vivo, los diferentes procesos típicamente comunican a través de la base de datos. IE, el proceso de IU escribe cambios en una tabla y el proceso de fondo sondea esa tabla para ver los cambios. Sí, es horrible. Para las pruebas de integración, configuro un sistema usando la UI y capturo ese estado con DbUnit. Entonces puedo ejecutar pruebas contra esa "entrada".

Mi componente y todos los componentes nuevos están gestionados por maven. Las conexiones DB actualmente están codificadas de forma rígida en la configuración de prueba. El sistema DbUnit funciona; Me gustaría poder cambiar la base de datos a la que hacen referencia mis pruebas dependiendo de si están siendo ejecutadas por mí en mi entorno de desarrollo o ejecutadas por Jenkins en el entorno de prueba.

Respuesta

5

Suponiendo que se puede externalizar los parámetros de conectividad de base de datos para sus pruebas en un archivo .properties o .xml, y que está utilizando Maven, a continuación, un enfoque consiste en utilizar las propiedades de Maven (y perfiles opcionalmente) para definir cada entorno, y el uso el filtrado de recursos para configurar estas propiedades en su archivo de configuración.

Por ejemplo, supongamos que durante las pruebas que se las arreglan para exteriorizar sus parámetros de conectividad de base de datos en un archivo llamado datasource.properties en src/test/resources que tiene este aspecto:

datasource.driverClassName = ${test.datasource.driverClassName} 
datasource.url = ${test.datasource.url} 
datasource.username = ${test.datasource.username} 
datasource.password = ${test.datasource.password} 

Y usted tiene esto en su POM:

<build> 
    <testResources> 
    <testResource> 
     <directory>src/test/resources</directory> 
     <filtering>true</filtering> 
    </testResource> 
    </testResources> 
</build> 

Luego podría definir las propiedades test.datasource.driverClassName etc. de varias maneras para decirle a Maven que use diferentes bases de datos:

  • Puede definir los valores predeterminados en la sección <properties> de su POM;
  • Puede definir bases de datos específicas del usuario en la sección <properties> de cada desarrollador (y Jenkins ') settings.xml;
  • Puede definir algunos perfiles en su POM para diferentes entornos (por ejemplo, development, jenkins, anotherDB) y ejecutar su compilación con diferentes perfiles.

Si opta por la última opción, puede hacer que Jenkins se ejecute en varias bases de datos realizando múltiples construcciones Maven a partir de un proyecto de Jenkins, que difieren solo por perfil. Dicho esto, sería mejor tener diferentes proyectos de Jenkins para cada entorno.

1

Necesita saber más acerca de su herramienta de compilación. ¿Estás usando Maven? ¿Dónde está almacenada la información de conexión de su base de datos? ¿Estás usando primavera?

Lo hago actualmente, utilizo Maven con propiedades para mi conexión de base de datos principal y un conjunto separado de propiedades para la conexión de mi base de datos de prueba.

Como utilizo Spring, dentro de los recursos de prueba maven tengo un archivo applicationContext que contiene mi bean de fuente de datos y hace referencia a las propiedades de la prueba.

<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy- method="close"> 
    <property name="driverClassName" value="${test.jdbc.driverClassName}"/> 
    <property name="url" value="${test.jdbc.url}"/> 
    <property name="username" value="${test.jdbc.username}"/> 
    <property name="password" value="${test.jdbc.password}"/> 
    <property name="maxActive" value="100"/> 
    <property name="maxWait" value="1000"/> 
    <property name="poolPreparedStatements" value="true"/> 
    <property name="defaultAutoCommit" value="true"/> 
</bean> 
+0

Soy vergonzosamente noblemente cuando se trata de Spring, pero lo poco que sé me lleva a pensar que puede ser una solución útil. Tengo la impresión de que configuró orígenes de datos en xml y anota sus clases para la inyección de dependencias en tiempo de ejecución. ¿Spring podría cambiar qué DB se inyecta en función del entorno (desarrollo vs. prueba)? –

+0

Tiene razón acerca de la configuración de la conexión de la base de datos en XML. Pero para lo que está tratando de lograr, creo que realmente debería centrarse en lo que Maven va a hacer por usted y en cómo las propiedades y perfiles de Maven para su compilación se pueden utilizar para personalizar su compilación y ejecutar sus pruebas. Maven puede ejecutar las pruebas de su unidad y tiene recursos que se usan solo en la fase de prueba, luego puede usar otro conjunto de recursos para su compilación principal, yendo a cualquier entorno. Jenkins ejecuta maven builds, para que puedas simular en tu máquina exactamente las mismas cosas que Jenkins va a hacer. – BenSchro10

1

Mucho depende de su entorno de despliegue. Si se está implementando en un contenedor (tomcat, jboss, etc.), el uso de una conexión JNDI lo aislará del entorno de base de datos. Si está creando un programa java autónomo, tendrá que determinar el entorno por su cuenta y elegir qué perfil de conexión de db utilizar.

Una forma de hacerlo es tener una configuración de base de datos separada por entorno, e incluir eso en su implementación. De esta manera no tiene que complicar su código con la preocupación sobre en qué entorno está.

La otra forma es pasar el entorno a su programa y dejar que su código descubra qué configuración usar.

+0

He editado mi publicación para incluir más información. Tengo curiosidad sobre el formato de la "configuración de base de datos separada" que mencionas. ¿Es eso un archivo .properties (usando ResourceBundle), o un XML (usando alguna otra herramienta), o algo completamente diferente? Podría poner cadenas de conexión de jdbc en un archivo y leer ese archivo, pero eso se siente hackish. Mi suposición es que existe una herramienta/práctica/formato para hacerlo de una manera más estándar. Simplemente no sé qué estándar es. –

+0

.propreties archivos, o XML. Yo usaría archivos .properties yo mismo, más bien desprecio a XML. –

Cuestiones relacionadas