Compartir clases src/test entre módulos en un proyecto maven de varios módulos

5 minutos de lectura

Tengo un proyecto Maven de varios módulos. Por el bien de este ejemplo, considere dos módulos:

  • data
  • consumer

Módulo consumer tiene modulo data como dependencia.

Módulo data declara un montón de clases principales. Hay pruebas bajo src/test que los use. Estas pruebas requieren una creación de objetos prolija, por lo que tengo una clase con algunos métodos de utilidad para crear estos objetos. Esta clase de utilidad (SampleDataHelper) está en el src/test jerarquía.

También tengo algunas pruebas en el consumer módulo que necesita para crear algunos de estos objetos de largo aliento. quiero usar mi SampleDataHelper clase (definida en data src/test) en las pruebas que residen en mi consumer src/test árbol. Desafortunadamente, aunque data es una dependencia de consumer, consumer no puedo ver las clases que existen bajo data src/test.

Para combatir esto, pensé que podría crear otro módulo (data-test), y mover SampleDataHelper debajo src/main. Entonces incluiría data-test como un ámbito de prueba dependencia de data. Desafortunadamente, esto introduce una dependencia circular: data usos data-testpero data-test también requiere data.

La única solución que he encontrado es colocar SampleDataHelper por debajo data src/main debajo de test paquete y espero que ningún código de aplicación real lo llame.

¿Cómo puedo compartir mi SampleDataHelper clase entre módulos sin que poniéndolo debajo src/main?

  • Mira esta respuesta. Creo que debería ayudarte.

    – Andrew Logvinov

    6 de febrero de 2013 a las 6:31

  • Para futuros lectores: Guía Maven para usar pruebas adjuntas

    – Greg Kopff

    6 de febrero de 2013 a las 6:36

  • @AndrewLogvinov: ¿su respuesta vinculada no requeriría una compilación de “dos pasos”? Para construir primero y desplegar un módulo (data) antes de que pueda compilar mi segundo módulo (consumer).

    – Greg Kopff

    6 de febrero de 2013 a las 6:42

  • creo que usted puede que encuentra algunos problemas si usa mvn packagepero debería funcionar bien en una compilación de un solo paso cuando usa mvn install o mvn deploy. Solo una nota rapida. En uno de nuestros grandes proyectos tenemos un wrapper sobre junit’s TestBase y se encuentra en src/main que tampoco considero una buena idea.

    – Andrew Logvinov

    6 de febrero de 2013 a las 6:58

avatar de usuario
duncan jones

Su proyecto de Consumidor depende de su proyecto de Datos, por lo tanto, nos complace que los Datos deban construirse antes que los de Consumidor. Como resultado, usando las técnicas sugeridas en los comentarios, me aseguraría de que su proyecto de datos contenga todo el código de prueba que desea compartir y configurar el POM para producir un JAR de prueba:

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

Su proyecto de Consumidor dependería tanto del artefacto Data JAR normal como del adicional test-jar artefacto, con alcance de prueba, por supuesto:

<dependency>
  <groupId>com.foo</groupId>
  <artifactId>data</artifactId>
  <version>1.0</version>
  <type>test-jar</type>
  <scope>test</scope>
</dependency>

He usado este enfoque en muchas ocasiones y funciona bien.

  • con respecto a “Su proyecto de Consumidor dependería tanto del artefacto Data JAR normal, como de la parte adicional del artefacto jar de prueba”, cuando agrego ambas dependencias de datos en el consumidor (digamos que mis artefactos también se denominan datos y consumidor) pom, sin especificación de versiones específicas, el pom obtuvo un error. ¿Por qué sucede eso?

    – Juan

    20 de agosto de 2015 a las 13:17

  • @StasS probablemente sea mejor que abra una pregunta separada sobre eso.

    –Duncan Jones

    21 de agosto de 2015 a las 11:39

  • Lo hice 🙂 stackoverflow.com/questions/32119591/…

    – Juan

    21 de agosto de 2015 a las 12:57

avatar de usuario
Matsev

Así que el problema es que (algunas) pruebas en el data módulo depende de la SampleDataHelper ¿clase? Puedes mover el SampleDataHelper clase a src/main del data-test módulo, si al mismo tiempo mueve las pruebas (que dependen de la clase específica) al src/test del data-test módulo. En consecuencia, no habría más dependencias circulares.

  • Si lo entiendo, está sugiriendo que cualquier prueba que use SampleDataHelper ser movido desde el data módulo o el consumer módulo (según corresponda) en data-test. Desafortunadamente, no encuentro que esta sea una solución muy “limpia”, ya que mueve mis pruebas fuera del módulo que prueban y dentro de uno diferente. (Estrictamente hablando, solo dijiste que movieras el data pruebas, pero creo que me encontraría moviendo ambos por consistencia). Pero gracias por tu respuesta. 🙂

    – Greg Kopff

    6 de febrero de 2013 a las 6:48


  • Sí, me entendiste bien. Y podría decirse que es más una solución rápida que una buena. 🙂

    – Matsev

    6 de febrero de 2013 a las 7:48

  • Me imagino que las dependencias circulares permanecerían. Suponiendo que las pruebas en cuestión ejerzan las clases definidas en el proyecto de datos, aún sería necesario que hubiera una referencia al proyecto de datos desde el proyecto de prueba de datos.

    –Duncan Jones

    6 de febrero de 2013 a las 7:49

  • @DuncanJones Lo siento, hubo un pequeño error tipográfico en mi publicación. El punto que estoy tratando de hacer es que el data-test El módulo debe depender del data módulo (y no al revés). Para evitar la dependencia circular, todas las pruebas que residen actualmente en el data módulo que utiliza el SampleDataHelper debe trasladarse a la data-test módulo.

    – Matsev

    6 de febrero de 2013 a las 8:15

  • Te tengo, eso tiene más sentido.

    –Duncan Jones

    6 de febrero de 2013 a las 9:47

¿Ha sido útil esta solución?