Code-Coverage, Eclipse, jUnit

eclemma-1

Joa, es ist wieder Zeit für einen Artikel in der Java/DA-Reihe.

Als erstes und sehr einfach zu testendes Kriterium gilt beim Testen die Code Coverage. Eigentlich sehr simpel, denn es quantifiziert nur die Code-Coverage, also von wie vielen Zeilen Code (Instructions) tatsächlich wie viele (bzw. welche) auch ausgeführt werden. Da man dies natürlich gerne automatisiert machen möchte, sind Tests wie mit jUnit ideal. Aber, auch normale Anwendungen sind mitzutracen und den Codecoverage ist zu ermitteln.

eclemma-2

Für Eclipse gibt es dazu ein prima Plugin namens EclEmma. Und auch schnell über die Update-URL im Manager installiert. EclEmma dient dabei als eine Art Wrapper für verschiedene Launchtypen – also beispielsweise als normale Applikation oder einen jUnit-Test bzw eine ganze Suite (Plugins). Das Ergebnis wird nach Beendigung des Programms/Tests innerhalb von Eclipse in einer Baumstruktur dargestellt; sehr schön ist auch die grafische Hervorhebung direkt im Sourcecode. Alternativ kann man sich das Ergebnis auch als HTML exportieren lassen.

TestSuites in Eclipse mit jUnit 4 (Nachtrag)

Das Problem: Wenn man in einem Projekt eine Reihe von Testcases gemacht hat, dann sind diese meist (natürlich) auf verschiedene Packages verteilt. Außerdem gibt es ja reine Komponententests als auch Usecasetests (soweit möglich), oder das Testen zweier oder mehrere Komponenten im Verbund. Schlussendlich also eine große Anzahl von „TestCase“-Klassen, die jeweils mehrere Tests haben. Ideal wäre also, wenn man diese ganzen Testcases zusammenpacken könnte.. und dann auch ausführen könnte.

jUnit bietet (in Eclipse) dafür die Option TestSuite an. Eine TestSuite ist ja auch genau das, was wir brauchen. Leider zeigt der Wizard keine unserer TestCases an.. warum? Nach einigem Recherchieren (viele Suchergebnisse zeigen indirekt noch auf jUNit 3.8) ist die Frage eigentlich simpel gelöst.. wenn man denn weiß, wie 😉

Als erstes müssen alle TestCase-Klassen (d.h. hier die Klasse MyTests, die @Test-Methoden enthält) eine neue Methode erhalten:

public static junit.framework.Test suite() {
return new JUnit4TestAdapter(MyTests.class);
}

Damit erkennt der Wizard für eine TestSuite nun auch jene Klassen.

Falls man es lieber manuell machen möchte (Beispiel): suite.addTest(MyTests.suite());f

Es ist übrigens kein Problem, TestSuites zu verschachteln – dafür einfach das Prozedere „wiederholen“ bzw. suite.addTest(MyOtherSuite.suite()) schreiben. Tipp: Es gibt die äußerst hilfreiche Methode suite.setName(string) – damit man sich in der jUnit-Baumansicht nicht verwirrt.

Nachtrag:

Wesentlich eleganter ist natürlich der Annotation-Weg. Die „SuperTestSuite“ braucht „nur“ so auszusehen:

@RunWith(Suite.class)
@SuiteClasses( { MySuite1.class, MySuite2.class, MySuite3.class })

public class AllTests {
}

Statische Code-Analysetools für Java

Um die Softwarequalität zu verbessern, werde ich mir in den nächsten Java-gestützen Projekten einmal diese beiden Tools angucken. Im Vergleich schneidet PMD etwas besser als FindBugs ab, wir werden es sehen.

Ernüchterned ist es ja schon irgendwie, wenn man sein Fehler- und Warnungsfreie Projekt (Eclipse Compiler läßt grüßen) damit checkt und vor Hunderten Fehlern steht..