Couverture de code Java dans Hudson

Question

Je suis en train de migrer quelques projets d'une construction de fourmis vers une autre. Le serveur de compilation est et restera Hudson.

J'ai des problèmes pour enregistrer la couverture de code dans hudson avec cobertura en raison des tests. courir et enregistrer deux fois le problème .

Le projet est multi-module et il serait bien, bien que non nécessaire, de disposer d'une sortie agrégée des données de couverture de code.

Dans l’ensemble, la solution que je cherche doit absolument:

• exécuter des tests automatisés pour tous les modules et enregistrer les résultats une fois ;
• affiche la couverture de code de module individuel dans Hudson ;
• être facilement configuré une fois pour l'ensemble du projet , pas dans tous les modules.

La solution peut être basée sur Cobertura, Emma ou tout autre outil de couverture de code java.

Mise à jour : l'exécution des tests avec Emma duplique toujours les résultats et il n'existe aucune fonctionnalité de fusion . Par conséquent, il n'est pas vraiment utilisable avec des versions à plusieurs modules.

Answer 1

Sonar est un outil très cool qui s'intègre facilement à Hudson. J'aime beaucoup son organisation avec projets de module. Vous devriez faire un essai

texte alternatif http://sonar.codehaus.org/ wp-content / uploads / 2009/08 / dashboard.png

Answer 2

C’est un peu hackish, mais l’approche que j’utilise est d’utiliser un version modifiée du plugin Maven cobertura (qui est disponible à partir de leur référentiel ). Il fournit une cible cobertura: generate-report, afin que vous puissiez insérer cobertura: instrument et cobertura: generate-report dans votre cycle de vie avant et après l'exécution des tests, respectivement. Vous obtiendrez les données de couverture souhaitées sans l'exécution / l'enregistrement de test en double.

Le problème sous-jacent est que tous les plug-ins de couverture Maven non clover que j'ai rencontrés sont construits autour de l'idée d'exécuter les tests avec une couverture séparément de l'exécution principale du cycle de vie Maven. Cela entraîne évidemment deux séries d’exécutions de test. Si vous utilisez un projet de style libre, vous n’enregistrerez qu’un seul ensemble de tests (car, même avec deux exécutions de test, il n’existe qu’une seule copie de la sortie de test), mais le type de projet Maven intercepte en réalité les exécutions de Maven mojo et enregistre les résultats / tests de test au moment de l'exécution du test, plutôt que tous en même temps à la fin de la construction, comme le font les projets de style libre. Cela présente de nombreux avantages, mais présente également l’inconvénient plutôt flagrant qu’un seul test exécuté deux fois est compté comme deux tests.

Cela dit, même si j’ai vu de solides arguments en faveur de la réalisation de tests avec du code non instrumenté et du code instrumenté, je préfère exécuter les tests une seule fois, contre du code instrumenté - non seulement à cause des problèmes Maven / Hudson, mais Lorsque vous avez des tests qui prennent 45 minutes, il semble franchement ridicule de les exécuter deux fois pour obtenir le même résultat.

Answer 3

Robert,

J'ai également eu ce problème et j'ai constaté qu'Hudson ne signalait pas deux fois si vous configuriez le projet en tant que projet de style libre plutôt que de projet Maven2. Vous perdez un peu de la gentillesse d'avoir un projet Maven2, mais pour nous, c'était un métier que nous devions faire.

Jeff

Answer 4

Nous utilisons des projets de style libre et n'avons pas ce problème. Ainsi, comme indiqué, cela peut être la source de votre problème.

Pour fournir les fonctionnalités de fusion, nous avons créé notre propre référentiel d'artefacts (nous n'utilisons pas Maven). À la fin de chaque génération, nous copions le fichier cobertura.ser sur un partage réseau, en le renommant par la suite. Nous avons un travail de vue consolidée qui copie tous les fichiers cobertura et les fichiers de code source (un autre artefact de construction copié sur le partage réseau) dans le répertoire de construction local et génère le rapport Cobertura.

L'absence d'un référentiel d'artefacts standard dans Hudson est un peu frustrant, mais il est logique de laisser les auteurs utiliser généralement Maven pour ces besoins. Notre processus de génération s’appuyant sur plusieurs serveurs, nous ne pouvons donc pas simplement utiliser des chemins relatifs dans les autres répertoires de travail.

Notez que nous faisons la même chose pour d’autres métriques: résultats de test, JavaNCSS, etc. et rejoint soit en utilisant les outils appropriés ou un code personnalisé.

Nous utilisons le même référentiel pour les artefacts de construction traditionnels: DLL, JAR, scripts d'installation.

Answer 5

Reportez-vous à la section Couverture de test Java SD pour obtenir un outil à très faible surcharge avec une interface graphique agréable. Je ne suis pas sûr de comprendre votre "exécution deux fois". problème, mais si vous avez exécuté deux fois (le même déterministe) des tests avec les outils SD, vous obtiendrez les mêmes données de couverture de test, par exemple son idempotent. Si vos tests ne sont pas déterministes, vous aurez deux exécutions de test différentes, mais ces outils fusionnent facilement les résultats de plusieurs exécutions en un seul résumé global.

Ils gèrent également des applications extrêmement volumineuses, et gèrent plutôt bien plusieurs applications à threads (de petits éclats de synchronisation peuvent rendre la réponse légèrement inexacte en théorie, mais la pratique n’est tout simplement pas un problème).

Answer 6

Avez-vous envisagé de le trèfle d'Atlassian ?

Le plugin maven-clover2 a un nouvel objectif: clover2: setup qui instrumentera simplement vos tests sans forger le cycle de vie ni exécuter deux fois les tests.

Vous définiriez les objectifs à exécuter dans Hudson comme suit:

mvn clover2:setup verify clover2:aggregate clover2:clover

Le plugin maven-clover2 est absolument gratuit pendant 30 jours.