2016-07-15 15 views
0

Wir machen eine Reihe von automatisierten Tests gegen eine vollständig implementierte Java-Webanwendung (zusätzlich zu Komponententests) und möchten die Codeabdeckung dieser Tests verfolgen. Die App ist in Java geschrieben und läuft auf Tomcat. Wir verwenden derzeit Cobertura, um die Abdeckung für unsere Komponententests zu erfassen, also möchte ich bei Cowertura bleiben. Ich habe unseren Krieg instrumentiert und kann Berichte aus der Datei coberura.server generieren, aber es zeigt immer eine Abdeckung von 0%.Cobertura zeigt 0% Abdeckung für instrumentierte WAR in Tomcat

Hier sind die Schritte, die ich bin nach:

  1. Bauen Sie das Glas und Krieg in den normalen Prozess (kein Instrumentierung). Unsere Anwendungsklassen werden in eine JAR-Datei gepackt, die dann in den Lib-Director des von uns bereitgestellten Kriegs gestellt wird.
  2. Packen Sie sowohl das Glas und Krieg
  3. Rebuild wieder aber dieses Mal Instrument die Klassen.
  4. Kopieren Sie die instrumentierten Klassen in das entpackte jar-Verzeichnis. Ich mache das, weil das Instrumentieren scheinbar keine Klassendateien für Dinge ausgibt, die keinen ausführbaren Code haben (wie Schnittstellen).
  5. Baue das Glas aus dem entpackten Glasverzeichnis
  6. Füge das neue instrumentierte Glas und die cobertura.jar zum lib Verzeichnis des entpackten Kriegsverzeichnisses hinzu und baue daraus einen Krieg.
  7. Fügen Sie den neuen instrumentierte Krieg und coberturaFlush.war zum Kater webapps Verzeichnis
  8. hinzufügen cobertura.ser (das wurde während der Instrumentierung erzeugt) zu tomcat Verzeichnis sind
  9. Starten Sie Tomcat
  10. Sie Sachen in der App
  11. Hit/coberturaFlush/flushCobertura in einem Browser.
  12. Stopp Tomcat
  13. Verwenden cobertura-report.bat den Bericht aus der cobertura.ser Datei ist

Hier zu erzeugen, was ich bisher ausprobiert habe:

  • I bestätigt die Klassendateien im Jar haben Verweise auf Cobertura, also bin ich zuversichtlich, dass sie instrumentiert sind.
  • Ich benutze coberturaFlush.war, weil ich eine Reihe von NoClassDefFound-Fehlern bekomme, wenn ich die App stoppe, so dass es nicht so aussieht, als ob der Shutdown-Haken richtig funktioniert. Dies scheint ein häufiges Problem zu sein und CoberturaFlush scheint eine vernünftige Lösung zu sein.
  • Ich bin zuversichtlich, dass Cobertura die richtige .ser-Datei verwendet. Wenn Tomcat startet, sehe ich, dass einige Dateien schnell auf 0KB heruntergehen und eine cobertura.server.lock-Datei erstellt und dann wieder auf die ursprüngliche Größe zurückgesetzt und die Sperrdatei gelöscht wird. Ich sehe das gleiche passieren, wenn ich flushCobertura anrufe, sowie wenn ich Tomcat herunterfahre.
  • Ich habe auch versucht, Berichte mit der Datei .ser zu erstellen, nachdem ich flush, aber bevor ich Tomcat stoppe und das hat auch nicht funktioniert.

Fehle ich etwas? Irgendeine Idee, warum Cobertura immer 0% Deckung sagt?

Vielen Dank im Voraus.

Antwort

0

Ich denke, Sie können in "JAR-Hölle" sein. Ich war das gleiche Problem, und war in der Lage, um es zu erhalten, indem:

  1. Nicht die cobertura.jar Datei in der Webapp Umgebung gehören
  2. die cobertura.jar Datei kopieren Sie auf die Tomcat common library directory

coberturaFlush sucht nach der Lib auf der Tomcat-Ebene; Wenn Sie eine andere Instanz innerhalb der Web-App haben, sind die Zähler für die Webanwendung von den gesamten Tomcat-Zählern getrennt.

Eine andere Alternative, nicht die beste, aber es funktioniert, ist Ihre Webapp die saveGlobalProjectData Methode aufrufen, wie in der Cobertura FAQ beschrieben. Beide Methoden funktionierten für mich, aber da ich meiner App keinen speziellen Code hinzufügen wollte, wählte ich den ersten.