Cobertura del código Java en Hudson

Question

Estoy migrando un par de proyectos de una construcción ant a una maven. El servidor de compilación es, y seguirá siendo, Hudson.

He tenido problemas para registrar la cobertura del código en Hudson con cobertura debido a las pruebas ejecutar y grabar dos veces problema .

El proyecto es de múltiples módulos y sería bueno, aunque no es obligatorio, tener una salida agregada de los datos de cobertura del código.

En general, la solución que estoy buscando debe:

• ejecute pruebas automatizadas para todos los módulos y registre los resultados una vez ;
• muestra la cobertura de código de módulo individual en Hudson ;
• configurarse fácilmente una vez para todo el proyecto , no en todos los módulos.

La solución puede basarse en Cobertura, o Emma, ??o cualquier otra herramienta de cobertura de código Java.

---

Actualización : la ejecución de las pruebas con Emma todavía duplica los resultados y no existe la capacidad merge , por lo que no es realmente utilizable con compilaciones de varios módulos.

Answer 1

Sonar es una herramienta muy interesante que se integra fácilmente con Hudson, realmente me gusta su organización con múltiples proyectos modulares. Deberías probarlo

texto alternativo http://sonar.codehaus.org/ wp-content / uploads / 2009/08 / dashboard.png

Answer 2

Es un poco hack, pero el enfoque que estoy usando es usar un versión modificada del complemento de cobertura de Maven (que es disponible en su repositorio ). Proporciona un objetivo de cobertura: generar-informe, para que pueda insertar cobertura: instrumento y cobertura: generar-informe en su ciclo de vida antes y después de ejecutar las pruebas, respectivamente. Eso le proporcionará los datos de cobertura que desea sin la ejecución / grabación de prueba duplicada.

El problema subyacente es que todos los complementos de cobertura de Maven sin trébol con los que me he encontrado se basan en la idea de ejecutar las pruebas con cobertura por separado de la ejecución de la prueba principal en el ciclo de vida de Maven. Esto, obviamente, da como resultado dos conjuntos de ejecuciones de prueba. Si está utilizando un proyecto de estilo libre, solo obtendrá un conjunto de pruebas grabadas (ya que, incluso con dos ejecuciones de prueba, solo hay una copia de la salida de prueba), pero el tipo de proyecto Maven realmente intercepta las ejecuciones de Maven mojo y registra los resultados / resultados de la prueba en el momento de la ejecución de la prueba, en lugar de todos a la vez al final de la compilación como lo hacen los proyectos de estilo libre. Esto tiene muchas ventajas, pero también tiene la desventaja bastante evidente de que una sola prueba que se ejecuta dos veces se cuenta como dos pruebas.

Dicho esto, si bien he visto fuertes argumentos para ejecutar pruebas tanto contra código instrumentado como no instrumentado, prefiero ejecutar solo las pruebas una vez, contra código instrumentado, no solo por los problemas de Maven / Hudson, sino porque cuando tienes pruebas que toman 45 minutos, parece francamente tonto ejecutarlas dos veces para generar el mismo resultado.

Answer 3

Robert,

También tuve este problema y descubrí que Hudson no informa dos veces si configura el proyecto como un proyecto de estilo libre en lugar de un proyecto Maven2. Se pierde algo de la bondad de tener un proyecto maven2, pero para nosotros fue un cambio que tuvimos que hacer.

Jeff

Answer 4

Utilizamos proyectos de estilo libre y no tenemos este problema, por lo que, como se indicó, esta puede ser la fuente de su problema.

Para proporcionar las funciones de fusión, creamos nuestro propio repositorio de artefactos (no estamos usando Maven). Al final de cada compilación, copiamos el archivo cobertura.ser a un recurso compartido de red, renombrándolo en el proceso. Tenemos un trabajo de vista consolidado que copia todos los archivos de cobertura y los archivos de código fuente (otro artefacto de compilación copiado al recurso compartido de red) en el directorio de compilación local y genera el informe de Cobertura.

La falta de un repositorio de artefactos estándar en Hudson es un poco frustrante, pero tiene sentido dar a los autores que usen Maven para esas necesidades. Nuestro proceso de compilación se ejecuta en varios servidores, por lo que no podemos usar rutas relativas en los otros directorios de trabajo.

Nota, hacemos lo mismo para otras métricas: resultados de pruebas, JavaNCSS, ect. y se unió usando las herramientas correctas o algún código personalizado.

Utilizamos el mismo repositorio para los artefactos de compilación tradicionales: DLL, JAR, scripts de instalación.

Answer 5

Consulte SD Java Test Coverage para obtener una herramienta de gastos generales extremadamente baja con una buena GUI. No estoy seguro de entender tu " correr dos veces " problema, pero si realizó pruebas (el mismo determinista) dos veces con las herramientas SD, obtendrá los mismos datos de cobertura de prueba, por ejemplo, su idempotente. Si sus pruebas no son deterministas, obtendrá dos ejecuciones de prueba diferentes, pero estas herramientas combinan fácilmente los resultados de varias ejecuciones en un solo resumen general.

También manejan aplicaciones extremadamente grandes y manejan bastante bien múltiples aplicaciones de subprocesos (las pequeñas astillas de sincronización pueden hacer que la respuesta sea un poco inexacta en teoría, pero practicar esto simplemente no es un problema).

Answer 6

¿Ha considerado Atlassian's Clover ?

El complemento maven-clover2 tiene un nuevo objetivo: clover2: setup que simplemente instrumentará sus pruebas sin bifurcar el ciclo de vida, o ejecutar las pruebas dos veces.

Definiría los objetivos para correr en Hudson así:

mvn clover2:setup verify clover2:aggregate clover2:clover

El plugin maven-clover2-plugin es totalmente gratuito para probar durante 30 días.