Eclipse Insights: Code Coverage messen mit EclEmma

Wir werden nun – wie versprochen – einige der Dinge beschreiben, die wir den Standard-Eclipse-Paketen hinzugefügt haben. Den Anfang wollen wir mit einem unserer liebsten Eclipse-Plug-ins machen, nämlich EclEmma, das wir schon lange jeder Eclipse-Installation hinzugefügt haben und beinahe täglich nutzen. Mit diesem Tool lässt sich die Code Coverage von JUnit-Tests messen. Im Inneren greift es auf eine JaCoCo-Bibliothek zurück, lässt sich aber zudem wunderbar in die Eclipse-IDE integrieren, was die Durchführung von Tests im „Coverage-Modus“ samt anschließender Ausgabe der Resultate der Analyse zulässt. Um einen beliebigen Junit-Test zu starten, muss man einfach rechtsklicken und dann „Coverage As => Junit Test“ auswählen. Auf die gleiche Weise können auch Plug-in-Tests gestartet werden. Alternativ gibt es direkt neben „run“ und „debug“ einen neuen Eintrag auf der Launch-Toolbar.

Im folgenden simplen Beispiel soll die Methode testen, ob ein String länger als zwei und kürzer als neun Zeichen ist.

Der erste Test soll die Methode mit einem leeren String (zu kurz) und einem gültigen String (z.B. mit 4 Zeichen) überprüfen.

Nachdem der Test im „Coverage-Modus“ gelaufen ist, zeigt uns EclEmma folgendes Ergebnis:

Das Tool markiert Zeilen, die vom Testfall abgedeckt wurden, in grün. Abgedeckt bedeutet an dieser Stelle, dass diese Zeilen ausgeführt wurden, während rot markierte Zeilen nicht ausgeführt wurden. In unserem Beispiel wurde Zeile 8 offensichtlich nicht ausgeführt, also wurde die erwartete Exception bei einem null String nicht getestet. Gelbe Markierungen zeigen Bedingungen an, die nur teilweise durchgelaufen wurden. Jede Bedingung lässt verschiedene Branches zu, d.h. die Bedingung in Zeile 7 könnte sowohl wahr als auch falsch sein. Da unser Test für diese Bedingung nur falsche Werte ausgeben wird, fehlt ein Branch, weshalb Zeile 7 gelb markiert wird. Die Bedingung in Zeile 10 könnte ebenfalls wahr oder falsch sein, beide Fälle werden abgedeckt, dementsprechend deckt unser Test die Bedingung nicht voll ab. Da unsere Bedingung aus zwei Unterbedingungen besteht, die mit einem logischen UND verbunden sind, bestehen insgesamt vier Kombination, die getestet werden müssen. Fährt man über den gelben Diamanten in dieser Zeile, sieht man die fehlenden Branches. Im Augenblick führen wir noch nicht den Aspekt des Tests durch, in dem der zweite Teil der Bedingung – dass ein String nicht länger als neun Zeichen sein darf – falsch wird. Theoretisch müsste es sogar einen vierten Branch geben, praktisch können aber nicht beide Bedingungen falsch sein, da ein String nicht kürzer als 3 und gleichzeitig länger als 8 Zeichen sein kann.

Wir fügen also die fehlenden Testfälle hinzu und lassen EclEmma erneut laufen.

Jetzt zeigt uns EclEmma den ganzen Code in grün an:

EclEmma bietet außerdem eine Überblicksfunktion, die die Abdeckung von Klassen, Paketen und Projekten aufführt. Der Überblick zeigt die Abdeckung von vorherigen Tests an, insofern macht es Sinn, alle Tests für ein bestimmtes Projekt – also seine Testsuite – vorab durchlaufen zu lassen. Die Überblicksfunktion ist ein nützliches Tool, um Klassen zu identifizieren, die noch nicht ausreichend getestet wurden.

Microservices mit Spring Boot, Spring Cloud und Docker

In diesem Tutorial wird man auf den Umgang mit Microservices vorbereitet. Eberhard Wolff erklärt zunächst, was Microservices eigentlich sind und mit welchen Chancen und Herausforderungen die Arbeit mit ihnen verbunden ist. Nachdem die Grundlagen etabliert wurden, erklärt er den Umgang mit der Container-Sofware Docker und den Umgang mit dem Spring Framework, die anhand eines Micoservices-Beispiels in der letzten Lektion noch einmal praktisch angewendet werden.

JETZT LOSLEGEN

EclEmma ist ein nützliches Tool für die Entwicklung von Tests und um zu messen, wie viel Code von diesen abgedeckt wird. Allerdings gibt es immer Raum für Diskussionen. Was sagt beispielsweise die Messung überhaupt aus? Der Grad der Code Coverage selbst gibt wenig Aufschluss über Qualität und Umfang eines Tests. Wenn wir etwa in unserem Beispiel die letzte Zeile des Tests löschen würden, kämen wir weiterhin auf 100 Prozent Coverage, obwohl der Test dadurch vollständig nutzlos geworden wäre. Insofern kann es gefährlich sein, der hohen Abdeckung hinterherzujagen, weil dadurch eine Illusion von Sicherheit entstehen kann. Andersherum ist niedrige Coverage für gewöhnlich ein Zeichen für fehlende Tests.

Wie immer gilt natürlich, dass Tools nur dann Vorteile bringen, wenn sie verantwortungsbewusst angewendet werden. Unserer Ansicht nach hilft EclEmma vor allem dabei, fehlende Testfälle zu identifizieren. Deshalb empfehlen wir, erst die Tests zu schreiben, um danach die Coverage zu messen und möglicherweise fehlende Testfälle hinzuzufügen. Etwas allgemeiner betrachtet, helfen Code Coverage-Tools dabei, Pakete, Komponenten oder Klassen zu identifizieren, die unzureichend abgedeckt werden. Die globale Code Coverage auf einem Build Server gibt Entwicklern vielleicht einen Indikator für die Reichweite der aktellen Testbasis, man sollte sich aber darüber im Klaren sein, dass dieser ohne detailierte Untersuchung lediglich ein grober Fingerzeig sein kann.

Zusätzlich gibt es Tools, die noch einen Schritt weiter gehen und es Entwicklern erlauben, die Qualität der Test-Asserts zu überprüfen. Wir werden diese ebenfalls in unser Oomph-Profil integrieren und in einem zukünftigen Blogpost behandeln.

EclEmma ist eines der von uns am häufigsten genutzten Plugins für Eclipse und hat sich deswegen seinen Platz in unserem Eclipse Source Oomph Profile redlich verdient hat. An dieser Stelle wollen wir uns darum bei den Entwicklern, insbesondere bei Marc Hoffmann, für ihre tolle Arbeit bedanken.

Wenn Sie andere Tools kennen, ist es natürlich jederzeit möglich, diese in ihr IDE zu installieren und somit ihr Oomph Profile zu erweitern. Wenn sie ein Plugin für besonders interessant halten und es anderen Usern zugänglich machen wollen, kontaktieren Sie uns, dann können wir es dem Originalprofil hinzufügen.

Probleme und Feedback können Sie uns über das Github-Projekt mitteilen.

In unserem nächsten Beitrag werden wir einige weitere Plugins aus unserem Profil beschreiben. Einen Überblick über alle Blogeinträge finden sie unter diesem Link. Wir werden außerdem alle Profil-Updates auf diesem Blog posten. Folgen Sie uns, um auf dem Laufenden zu bleiben!

Bis dahin wünschen wir viel Spaß mit unserem EclipseSource-Oomph-Profil.

Im englischen Original erschienen auf dem EclipseSource Developer Blog, einem Blog über Eclipse-Technologien, Modellierung, RAP, Mobile-Entwicklung, sowie allgemeine Entwicklerthemen aus dem Java- und JavaScript-Umfeld.

Aufmacherbild: The eye of God Solar Eclipse von Shutterstock / Urheberrecht: Fernando Batista