2008-12-11 7 views
22

Tengo una clase de prueba en un módulo que amplía otra clase de prueba en uno de sus módulos de dependencia. ¿Cómo puedo importar el código de prueba de la dependencia en el ámbito de prueba del módulo dependiente?Clase de prueba que extiende la clase de prueba en el módulo de dependencia

Para analfabeto, tengo dos módulos, "módulo-uno" es una dependencia de "módulo-dos". SubTestCase es una subclase de TestCase.

 
module-one 
      \src\test\java\com\example\TestCase.java 
module-two 
      \src\test\java\com\example\SubTestCase.java 

Pero la acumulación está fallando debido a que el código de prueba de "módulo-uno" no se importa en "módulo de dos", sólo el código principal.

Respuesta

4

Normalmente esto se resuelve al compilar y desplegar los archivos modulename-test.jar además del archivo modulename.jar normal. Despliega estos en repos como artefactos regulares. Esto no es totalmente perfecto, pero funciona decentemente para artefactos de código.

Luego agregaría dependencias de ámbito de prueba a los tarros de prueba a otros módulos.

También puede resolver esto colocando artefactos de ámbito de prueba en ámbito "principal" en un módulo independiente y luego incluirlo en el alcance de prueba habitual en otros módulos. Esta solución no funciona muy bien en una compilación de varios módulos donde cada módulo exporta algunos artefactos de prueba, ya que básicamente obtienes módulos 2N.

Muchos de nosotros nos damos por vencidos en estas dos soluciones cuando nos damos cuenta de que el número de clases es bastante limitado y hay problemas asociados con ambas soluciones. Simplemente los colocamos en un paquete apropiadamente nombrado en el alcance "principal". Solo sigo olvidando por qué las dos primeras soluciones son un dolor.

31

Puede implementar el código de prueba como un artefacto adicional utilizando el maven-jar-plugin's test-jar goal. Se adjuntará al proyecto y se implementará con las pruebas del clasificador.

<plugin> 
    <groupId>org.apache.maven.plugins</groupId> 
    <artifactId>maven-jar-plugin</artifactId> 
    <executions> 
     <execution> 
     <phase>package</phase> 
     <goals> 
      <goal>test-jar</goal> 
     </goals> 
     </execution> 
    </executions> 
    </plugin> 

Otros proyectos pueden hacer referencia al jarrón de prueba al declarar el clasificador de pruebas en la dependencia.

<dependency> 
    <groupId>name.seller.rich</groupId> 
    <artifactId>foo</artifactId> 
    <version>1.0.0</version> 
    <classifier>tests</classifier> 
    <scope>test</scope> 
</dependency> 
+0

Trabajé brillantemente para mí, Rich, ¡gracias! Esta debería ser la respuesta aceptada. La respuesta de krosenvolds es una discusión justa, pero se pierde este uso muy apropiado de la característica maven-jar-plugin. –

+0

¿Las dependencias de las pruebas de foo también están incluidas? – TheConstructor

+0

Ok, prueba rápida dice no. ¿Alguna idea de cómo incluir fuentes de prueba y sus dependencias? – TheConstructor

8

En cuanto a la respuesta de Rich vendedor: El uso de <classifier>tests</classifier> está fuera de fecha ver la user’s guide.

Estoy usando maven 2.2.1 y maven-jar-plugin 2.2 y se requiere switch <type>test-jar</type> en lugar de <classifier>tests</classifier>.

Tenga en cuenta que las pruebas jar no son transitivas, por lo que es posible que deba agregarlas explícitamente.

<project> 
    ... 
    <dependencies> 
     <dependency> 
      <groupId>name.seller.rich</groupId> 
      <artifactId>foo</artifactId> 
      <version>1.0.0</version> 
      <type>test-jar</type> 
      <scope>test</scope> 
     </dependency> 
    </dependencies> 
    ... 
</project> 

actualización siguiente comentario Mike Sokolov:
gremio del usuario para Maven 3 actualizó el 28/03/2014 ver enlace anterior de ejemplo

Tenga en cuenta que las ediciones anteriores de esta guía sugiere utilizar < clasificador> prueba </clasificador> en lugar de < tipo> test-jar </type>. Si bien esto actualmente funciona para algunos casos, no funciona correctamente durante una construcción del reactor del módulo JAR de prueba y cualquier consumidor si se invoca una fase del ciclo de vida antes de la instalación. En tal escenario, Maven no resolverá la prueba JAR a partir de la salida de la construcción del reactor , sino desde el repositorio local/remoto. Aparentemente, el JAR de los repositorios podrían estar desactualizados o faltar por completo, causando una falla de compilación (vea MNG-2045).

+0

¿Las dependencias de las pruebas de foo también están incluidas? – TheConstructor

+0

Todas las dependencias de prueba de foo se incluirán automáticamente. Si Foo depende de las pruebas de barra, entonces debe aplicar el mismo enfoque para Foo/Bar Ver (respuesta de Rich) de lo contrario, foo no pasará la compilación de prueba –

+0

No es un conjunto de dependencias normales. Me gustó la idea de, por ejemplo, especificando en foo qué base de datos usar en las pruebas de integración y mantener la barra libre del nombre de db concreto. – TheConstructor

Cuestiones relacionadas