Mesurer la couverture de code pour les tests de script à distance

J'utilise EMMA Outil de couverture intégré à la phase de construction de projet de test unitaire, toutefois, la documentation de l'outil dit qu'il est assez simple d'obtenir une couverture de code à la situation que vous avez décrite.

CODE CODE est un excellent outil. Pour votre cas, vous devriez utiliser Interface de ligne de commande , que pourriez-vous intégrer avec PowerShell existant scripts.

afaik, tous les outils de couverture de code utilisent le même concept (je omettrai la pièce de rapport et de contrôle):

1. premier instrument le code (c'est-à-dire placer des marqueurs).
2. puis exécutez des tests pour exécuter le code instrumenté (pour activer les marqueurs et collecter des données).

   Pour la deuxième étape, le cas d'utilisation commune est en effet exécuter des tests JUNIT, mais vos tests ne doivent pas nécessairement être à des tests de junit. En fait, ils n'ont même pas besoin d'être automatisés.

   Et le code instrumenté ne doit pas être exécuté dans le contexte d'un test d'unité, il peut être emballé dans une guerre / une oreille et déployé sur un conteneur (cela nécessitera simplement un peu plus de travail).

   Pour Cobertura, c'est ce que nous pouvons lire dans le Foire aux questions :

   Utilisation de COBERTURA avec une application Web

   j'ai des tests automatisés qui utilisent Httpunit / htmlunit / empirix / rationnel Robot, puis-je utiliser coobertura?

   Oui! Le processus est un peu plus impliqué, mais le concept est le même. Premier instrument votre compilé Des classes. Puis créez votre fichier de guerre. Puis déployez le fichier de guerre dans votre Server d'application (Tomcat, JBoss, Weblogic, WebSphere, etc.). Maintenant courir vos tests.

   Comme vos cours sont accessibles, ils créera un fichier "coobertura.ser" sur le disque. Vous devrez peut-être creuser autour d'un peu pour le trouver. Cobertura met ça fichier dans ce qu'il considère comme le Répertoire de travail actuel. Typiquement c'est le répertoire que le Le serveur d'applications a été démarré à partir de (Par exemple, c: \ tomcat \ bin) Remarque: Ce fichier n'est pas écrit sur le disque jusqu'à ce que le serveur d'applications sort. Voir ci-dessous pour savoir comment travailler autour de cela.

   Maintenant que vous savez où le Le fichier coobertura.ser est, vous devriez modifier votre étape de déploiement afin qu'il déplace l'original coobertura.ser à le répertoire approprié dans votre serveur d'applications, puis le déplace retour lorsque des tests finis. Puis courir COBERTURA-REPORT.

   [...]

   Pour Emma, ​​c'est ce que le Documentation dit:

   3.11. Comment utiliser Emma in {Weblogic, WebSphere, Tomcat, JBoss, ...}?

   Tout d'abord, il y a peu de chances que vous puissiez utiliser le mode à la volée (Emmarun) avec un conteneur J2EE complet. La raison réside dans le fait que de nombreuses fonctionnalités J2EE nécessitent une charge de classement spécialisée qui se produira en dehors de EMMA Instrument Classloader. Le serveur peut fonctionner bien, mais vous n'obtiendrez probablement aucune donnée de couverture.

   Ainsi, la procédure correcte consiste à instrument vos classes avant le déploiement (mode hors ligne). L'instrumentation hors ligne suit toujours le même compile / instrument / package / déploiement / get de la couverture / générer des rapports séquences. Suivez ces étapes:

   1. Utilisez l'outil Instr de Emma pour instruminer les classes souhaitées. Cela peut être fait comme une étape post-compilation, avant l'emballage. Cependant, de nombreux utilisateurs trouvent également qu'il est également pratique de laisser Emma traite ses pots directement (sur place, en utilisant le mode d'écrasement, ou en créant des copies instrumentées séparées de tout, en mode FullCopy);
   2. Faites votre emballage J2EE comme normal, mais n'incluez pas Emma.jar en tant que Lib à ce niveau, c'est-à-dire dans votre .war, .e-urear, etc.
   3. Localisez selon le conteneur et copiez Emma.jar dans le répertoire STI / LIB / EXT. Si cela est impossible, ajoutez Emma.jar au serveur ClassPath (de manière spécifique au serveur);
   4. Déployez vos classes instrumentées, .jars, .wars, étendues, etc. et exercez-vous / testez votre application J2EE via vos tests de clientèle ou de manière interactive ou quelle que soit celle que vous le faites;
   5. Pour obtenir un fichier de vidage de couverture, vous avez trois options décrites dans les options pour contrôler lorsque EMMA décharge des données de couverture d'exécution ?. Il est fortement recommandé d'utiliser la commande de contrôle de couverture.get avec l'outil CTL disponible en V2.1.

      pour trèfle, cochez le Utilisation des applications distribuées Page .