Java: Codeabdeckung für Remote-Scripting-Tests messen

8

Wir haben eine Anwendung, die auf JBoss 5.1 bereitgestellt wird, JDK 1.6. Wir haben auch Skripte zum Testen in PowerShell geschrieben. Diese Skripte greifen über einen Web-Service auf die Anwendung zu. Ich möchte die Codeabdeckung der Skripte überprüfen. Irgendwelche Ideen? Die meisten der Tools, die ich gesehen habe, überprüfen eine JUnit Testabdeckung und ich sehe nicht, wie wir sie verwenden können. p>     

livnat peer 02.11.2009, 09:06
quelle

4 Antworten

6

AFAIK, alle Code-Coverage-Tools verwenden dasselbe Konzept (ich lasse den Berichts- und Überprüfungsteil weg):

  1. Erstes Instrument den Code (d. h. Marker platzieren).
  2. Führen Sie dann Tests aus, um den instrumentierten Code auszuführen (um Marker zu aktivieren und Daten zu sammeln).

Für den zweiten Schritt besteht der übliche Anwendungsfall zwar darin, JUnit-Tests auszuführen, aber Ihre Tests müssen nicht JUnit-Tests sein. Eigentlich müssen sie nicht einmal automatisiert werden.

Und der instrumentierte Code muss nicht im Rahmen eines Komponententests ausgeführt werden, er kann in einem WAR / EAR-Paket gepackt und auf einem Container bereitgestellt werden (dies erfordert nur etwas mehr Arbeit).

>

Für Cobertura können wir das in den Häufig gestellten Fragen nachlesen:

  

Verwendung von Cobertura mit einer Webanwendung

     

Ich habe automatisierte Tests, die verwenden   HttpUnit / HtmlUnit / Empirix / Rational   Roboter, kann ich Cobertura benutzen?

     

Ja! Der Prozess ist ein bisschen mehr   beteiligt, aber das Konzept ist das gleiche.   Erstes Instrument wird kompiliert   Klassen. Dann erstelle deine Kriegsdatei.   Stellen Sie dann die WAR-Datei in Ihrem   Anwendungsserver (Tomcat, JBoss,   WebLogic, WebSphere usw.). Jetzt lauf   Ihre Tests.

     

Wenn auf Ihre Klassen zugegriffen wird, werden sie angezeigt   erstellt eine "cobertura.ser" -Datei auf   die Scheibe. Sie müssen möglicherweise um einen herum graben   etwas zu finden. Cobertura bringt das zum Ausdruck   Datei in dem, was es für die   aktuelles Arbeitsverzeichnis In der Regel   Dies ist das Verzeichnis, das der   Anwendungsserver wurde von gestartet   (Beispiel: C: \ Tomcat \ bin) Hinweis:    Diese Datei wird nicht auf den Datenträger geschrieben   bis der Anwendungsserver beendet wird.   Siehe unten, wie Sie das umgehen können.

     

Nun, da Sie wissen, wo   cobertura.ser-Datei ist, sollten Sie   Modifizieren Sie Ihren Bereitstellungsschritt, so dass es   verschiebt den ursprünglichen cobertura.server nach   das entsprechende Verzeichnis in Ihrem   Anwendungsserver und verschiebt es dann   zurück, wenn das Testen abgeschlossen ist. Dann renne   Cobertura-Bericht.

     

[...]

Für Emma heißt es in der Dokumentation :

  

3.11. Wie verwende ich EMMA in {WebLogic, Websphere, Tomcat, JBoss, ...}?

     

Zunächst einmal besteht kaum eine Chance, dass Sie den On-The-Fly-Modus (emmarun) mit einem vollwertigen J2EE-Container nutzen können. Der Grund liegt in der Tatsache, dass viele J2EE-Funktionen ein spezielles Classloading erfordern, das außerhalb des EMMA-Instrumentierungs-Classloaders stattfindet. Der Server funktioniert möglicherweise einwandfrei, aber Sie erhalten wahrscheinlich keine Coverage-Daten.

     

Die korrekte Vorgehensweise besteht also darin, Ihre Klassen vor der Bereitstellung zu instrumentieren (Offline-Modus). Die Offline-Instrumentierung folgt immer der gleichen Kompilierungs / Instrumenten / Paket / Deploy / Get Coverage / Generate-Berichtssequenz. Befolgen Sie diese Schritte:

     
  1. Verwenden Sie das EMMA instr-Tool, um die gewünschten Klassen zu instrumentieren. Dies kann als Post-Compilierungsschritt vor dem Verpacken erfolgen. Viele Benutzer finden es jedoch auch bequem, EMMA ihre Dateien direkt verarbeiten zu lassen (entweder direkt vor Ort, im Überschreibmodus oder durch Erstellen separater instrumentierter Kopien von allem im Vollkopiermodus);
  2.   
  3. Machen Sie Ihre J2EE-Pakete wie gewohnt, aber nehmen Sie emma.jar nicht als Lib auf dieser Ebene auf, dh innerhalb Ihrer .war, .ear, etc;
  4.   
  5. Suchen Sie nach der JRE, die vom Container verwendet wird, und kopieren Sie emma.jar in das Verzeichnis / lib / ext. Wenn das nicht möglich ist, fügen Sie emma.jar (serverspezifisch) dem Server-Klassenpfad hinzu;
  6.   
  7. stellen Sie Ihre instrumentierten Klassen, .jars, .wars, .ears usw. bereit und üben / testen Sie Ihre J2EE-Anwendung über Ihre clientseitigen Testfälle oder interaktiv oder wie Sie es auch machen;
  8.   
  9. Um eine Coverage-Dump-Datei zu erhalten, haben Sie drei Optionen beschrieben unter Welche Optionen gibt es zu steuern, wenn EMMA Runtime-Coverage-Daten ablegt? Es wird dringend empfohlen, den Steuerbefehl coverage.get mit dem in Version 2.1 verfügbaren Tool ctl zu verwenden.
  10.   

Für Kleeblätter sollten Sie die Seite Mit verteilte Anwendungen arbeiten aufrufen.

    
Pascal Thivent 02.11.2009 11:43
quelle
2

Ich benutze das emma Coverage-Tool, das in die Build-Phase des Unit-Testing-Projekts integriert ist, jedoch die Dokumentation des Tools sagt , dass es ziemlich einfach ist, eine Code-Abdeckung in der von dir beschriebenen Situation zu erhalten.

    
denis.zhdanov 02.11.2009 10:05
quelle
0

Cover Code ist ein großartiges Werkzeug. In Ihrem Fall sollten Sie die Befehlszeilenschnittstelle verwenden, die Sie möglicherweise in vorhandene PowerShell-Skripts integrieren.

    
cetnar 02.11.2009 10:57
quelle
0

Ich schlage jacoco vor, da keine Änderungen am Quellcode erforderlich sind. Check out Messcodeabdeckung in (Tomcat) Java-Anwendungen mit einem GreyBox-Kabelbaum

    
Fabien Duchene 05.05.2013 15:53
quelle

Tags und Links