build - compile - Dependencias de prueba multiproyecto con gradle

gradle dependencias

Question

Tengo una configuración multiproyecto y quiero usar gradle.

Mis proyectos son así:

• Proyecto A

  • -> src/main/java
  • -> src/test/java

• Proyecto B

  • -> src/main/java (depende de src/main/java en el Proyecto A )
  • -> src/test/java (depende de src/test/java en el Proyecto A )

Mi proyecto B build.gradle es así:

apply plugin: ''java''
dependencies {
compile project('':ProjectA'')
}

La tarea compileJava funciona muy bien, pero compileTestJava no compila el archivo de prueba del Proyecto A.

Answer 1

Algunas de las otras respuestas provocaron errores de una forma u otra: Gradle no detectó clases de prueba de otros proyectos o el proyecto Eclipse tuvo dependencias no válidas cuando se importó. Si alguien tiene el mismo problema, sugiero ir con:

testCompile project('':core'')
testCompile files(project('':core'').sourceSets.test.output.classesDir)

La primera línea obliga al Eclipse a vincular el otro proyecto como dependencia, por lo que todas las fuentes están incluidas y actualizadas. El segundo permite a Gradle ver realmente las fuentes, sin causar ningún error de dependencia no válido como el testCompile project('':core'').sourceSets.test.output sí testCompile project('':core'').sourceSets.test.output hace.

Answer 2

En el Proyecto B , solo necesita agregar una dependencia testCompile :

dependencies {
...
testCompile project('':A'').sourceSets.test.output
}

Probado con Gradle 1.7.

Answer 3

La solución de Fesler no funcionó para mí, cuando intenté construir un proyecto de Android (gradle 2.2.0). Entonces tuve que hacer referencia a las clases requeridas manualmente:

android {
sourceSets {
androidTest {
java.srcDir project('':A'').file("src/androidTest/java")
}
test {
java.srcDir project('':A'').file("src/test/java")
}
}
}

Answer 4

Me he encontrado con este problema recientemente, y ¿es éste un problema difícil de encontrar para las respuestas?

El error que está cometiendo es pensar que un proyecto debe exportar sus elementos de prueba de la misma manera que exporta sus artefactos y dependencias primarios.

Lo que tuve mucho más éxito personalmente fue hacer un nuevo proyecto en Gradle. En tu ejemplo, yo lo nombraría

Proyecto A_Test -> src / main / java

Yo pondría en el src / main / java los archivos que tienes actualmente en el Proyecto A / src / test / java. Realice cualquier pruebaCompile dependencias de su proyecto A compila dependencias del Proyecto A_Test.

Luego, haga del Proyecto A_Test una pruebaCompile la dependencia del Proyecto B.

No es lógico hacerlo desde la perspectiva del autor de ambos proyectos, pero creo que tiene mucho sentido cuando piensas en proyectos como junit y scalatest (y otros. Aunque esos marcos están relacionados con las pruebas, no se consideran parte de los objetivos de "prueba" dentro de sus propios marcos: producen artefactos primarios que otros proyectos usan en su configuración de prueba. Solo desea seguir el mismo patrón.

Intentar hacer las otras respuestas enumeradas aquí no funcionó para mí personalmente (usando Gradle 1.9), pero he encontrado que el patrón que describo aquí es una solución más limpia de todos modos.

Answer 5

Nueva solución basada en testJar (dependencias dependientes soportadas) disponible como plugin de gradle:

https://github.com/hauner/gradle-plugins/tree/master/jartest

https://plugins.gradle.org/plugin/com.github.hauner.jarTest/1.0

De la documentación

En caso de que tenga una compilación gradle multiproyecto, puede tener dependencias de prueba entre subproyectos (lo que probablemente sea una pista de que sus proyectos no están bien estructurados).

Por ejemplo, suponga un proyecto donde el subproyecto Proyecto B depende del Proyecto A y B no solo tiene una dependencia de compilación en A sino también una dependencia de prueba. Para compilar y ejecutar las pruebas de B, necesitamos algunas clases de ayuda de prueba de A.

Por defecto, gradle no crea un artefacto de jar a partir de la salida de construcción de prueba de un proyecto.

Este complemento agrega una configuración testArchives (basada en testCompile) y una tarea jarTest para crear un jar del conjunto fuente de prueba (con la prueba del clasificador agregada al nombre del jar). Entonces podemos depender en B de la configuración testArchives de A (que también incluirá las dependencias transitivas de A).

En A, agregaríamos el complemento a build.gradle:

apply plugin: ''com.github.hauner.jarTest''

En B hacemos referencia a la configuración de TestArchives como esta:

dependencies {
...
testCompile project (path: '':ProjectA'', configuration: ''testArchives'')
}

Answer 6

Por favor, lea la actualización a continuación.

Problemas similares descritos por JustACluelessNewbie ocurren en IntelliJ IDEA. El problema es que la dependencia testCompile project('':core'').sourceSets.test.output realidad significa: "depende de las clases generadas por la tarea de compilación gradle". Por lo tanto, si abre un proyecto limpio donde las clases no se generan, IDEA no las reconocerá y notificará un error.

Para solucionar este problema, debe agregar una dependencia en los archivos fuente de prueba junto a la dependencia de las clases compiladas.

// First dependency is for IDEA
testCompileOnly files { project('':core'').sourceSets.test.java.srcDirs }
// Second is for Gradle
testCompile project('':core'').sourceSets.test.output

Puede observar dependencias reconocidas por IDEA en Configuración del módulo -> Dependencias (ámbito de prueba) .

Por cierto. esta no es una buena solución, por lo que vale la pena considerar la refactorización. Gradle tiene un subproyecto especial que solo contiene clases de soporte de prueba. Ver https://docs.gradle.org/current/userguide/test_kit.html

Actualización 2016-06-05 Más Estoy pensando en la solución propuesta menos me gusta. Hay algunos problemas con esto:

1. Crea dos dependencias en IDEA. Un punto para probar las fuentes de las clases compiladas. Y es crucial en qué orden estas dependencias son reconocidas por IDEA. Puede jugar con él cambiando el orden de dependencia en la configuración del Módulo -> pestaña Dependencias.
2. Al declarar estas dependencias, estás innecesariamente contaminando la estructura de dependencia.

Entonces, ¿cuál es la mejor solución? En mi opinión, está creando un nuevo conjunto de fuentes personalizado y poniendo clases compartidas en él. En realidad, los autores del proyecto Gradle lo hicieron al crear el conjunto fuente testFixtures.

Para hacerlo, solo tienes que:

1. Cree el conjunto de origen y agregue las configuraciones necesarias. Compruebe este complemento de scripts utilizado en el proyecto de Gradle: https://github.com/gradle/gradle/blob/master/gradle/testFixtures.gradle

2. Declarar la dependencia adecuada en el proyecto dependiente:

   dependencies {
   testCompile project(path: '':module-with-shared-classes'', configuration: ''testFixturesUsageCompile'')
   }

3. Importe el proyecto Gradle a IDEA y use la opción "crear un módulo separado por conjunto de origen" durante la importación.

Answer 7

Sé que es una vieja pregunta, pero tuve el mismo problema y pasé un tiempo averiguando qué estaba pasando. Estoy usando Gradle 1.9. Todos los cambios deben estar en build.gradle de ProjectB

Para usar clases de prueba de ProjectA en pruebas de ProjectB:

testCompile files(project('':ProjectA'').sourceSets.test.output.classesDir)

Para asegurarse de que la propiedad de sourceSets esté disponible para ProjectA:

evaluationDependsOn('':ProjectA'')

Para asegurarse de que las clases de prueba de ProjectA estén realmente allí, cuando compila ProjectB:

compileTestJava.dependsOn tasks.getByPath('':ProjectA:testClasses'')

Answer 8

Si tiene dependencias simuladas que necesita compartir entre pruebas, puede crear un nuevo proyecto projectA-mock y luego agregarlo como una dependencia de prueba para ProjectA y ProjectB :

dependencies {
testCompile project('':projectA-mock'')
}

Esta es una solución clara para compartir dependencias simuladas, pero si necesita ejecutar pruebas desde ProjectA en ProjectB use otra solución.

Answer 9

Una forma simple es agregar dependencia explícita de tareas en ProjectB:

compileTestJava.dependsOn tasks.getByPath('':ProjectA:testClasses'')

La forma difícil (pero más clara) es crear configuración de artefactos adicionales para ProjectA:

task myTestsJar(type: Jar) {
// pack whatever you need...
}
configurations {
testArtifacts
}
artifacts {
testArtifacts myTestsJar
}

y agregue la dependencia testCompile para ProjectB

apply plugin: ''java''
dependencies {
compile project('':ProjectA'')
testCompile project(path: '':ProjectA'', configuration: ''testArtifacts'')
}

Answer 10

en el proyecto B:

dependencies {
testCompile project('':projectA'').sourceSets.test.output
}

Parece que funciona en 1.7-rc-2