Tschüss, Cobertura

In meinem aktuellen Buch “Besser coden” zähle ich unter anderem Cobertura als Tools zum Ermitteln der Testabdeckung auf.

Gewohnheitsmäßig griff ich heuer auch in einem neuen Projekt zu Cobertura – und fand einen neuen Grund, über Softwarequalität zu schimpfen.

Gut, das ist jetzt ein bisschen unfair, denn die Entwickler von Cobertura sind nur halb schuld. Worin das Problem besteht?

Sobald ich Java-8-Syntax benutze, zum Beispiel eine Funktionsreferenz, wirft Cobertura eine ParseException. Es stellte sich heraus, dass der verwendete Java-Parser in JavaNCSS das nicht unterstützt – und auch nicht mehr weiterentwickelt wird (letztes Commit bei Github 2014, derzeit erschütternde 0 Contributors). Tatsächlich ist dieses Problem schon lange bekannt: Das zugehörige Issue wurde bereits im Juli 2014 eröffnet. In fast dreieinhalb Jahren hat es das Team von Cobertura nicht geschafft, das Problem zu beheben, etwa durch Migrieren zu einem anderen Parser.

Wir als Java-8-Entwickler, die längliche Stacktraces in Buildvorgängen eklig finden, ziehen die Konsequenz und wechseln das Tool.  Wie wär’s zum Beispiel mit OpenClover? Das ist die aktuelle Version des seit Juni 2017 geopensourceten Tools Clover von Atlassian. Eine Firma, die nicht gerade dafür bekannt ist, Schrott zu produzieren.

OpenClover lässt sich leicht in ein Maven-Projekt einklinken:

<build>
 <plugins>
  <plugin>
   <groupId>org.openclover</groupId>
   <artifactId>clover-maven-plugin</artifactId>
   <version>4.2.1</version>
  </plugin>
  ...
 </plugins>
</build>

Dann einfach wie folgt aufrufen:

mvn clover:instrument clover:check clover:clover

(Oder auch ins Maven-Reporting per mvn site einklinken, wie das geht steht hier)

Clover produziert damit eine hübsche, interaktive Webseite im Verzeichnis target/site/clover:

Abgesehen von der Testabdeckung erfasst OpenClover auch die Komplexität von Funktionen und die Ergebnisse von Unit-Tests und nimmt so ein paar anderen Tools die Arbeit ab.

OpenClover lässt sich leicht beibringen, bestimmten Code zu ignorieren, etwa Model-Klassen:

<configuration>
 <excludes>
  <exclude>**/model/*.java</exclude>
 </excludes>
</configuration>

 Außerdem können wir eine Mindestanforderung an die Testabdeckung einstellen: 

<configuration>
 <targetPercentage>50%</targetPercentage>
</configuration>

Stellt Clover einen zu niedrigen Wert fest, erzeugt es einen Build-Fehler. Bindet man diesen Vorgang in Mavens deploy-Phase ein, werden Artefakte mit zu geringer Testabdeckung eiskalt am Zutritt zum Repository gehindert.

Ein Eclipse-Plugin gibt’s auch (nicht über den Marketplace, sondern per Updatesite). Das Plugin zeigt ebenfalls ausführliche Statistiken und hinterlegt außerdem Codezeilen grün oder rot, je nachdem, ob sie von Tests durchlaufen wurden.

OpenClover steht unter Apache-Lizenz, so dass der Benutzung auch in dieser Hinsicht nichts im Wege steht.

 

Teilt eure Erfahrungen mit OpenClover! Ich bin gespannt, was ihr davon haltet.

Please follow and like us:
Pin Share