Suche
EclipseSource Oomph Profile, Teil 3

Eclipse Insights: Code Coverage messen mit EclEmma

Maximilian Kögel, Jonas Helming

(c)  Shutterstock / Fernando Batista

Wie schon in Teil 1 und Teil 2 der Eclipse-Insights-Kolumne beschrieben, stellen wir ein Eclipse-Oomph-Profil mit unseren bevorzugten Plug-ins und vorkonfigurierten Settings zur Verfügung. Wenn Sie Oomph benutzen, können sie diese Eclipse-Version mit nur einem Klick bekommen. Folgen Sie dazu diesem Link für das vorkonfigurierte Eclipse und eine ausführliche Einleitung.

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.

ESOP_EclEmma_01

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

ESOP_EclEmma_02

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

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

ESOP_EclEmma_04

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.

ESOP_EclEmma_05

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

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.

ESOP_EclEmma_07

entwickler.tutorial - Microservices

Microservices mit Spring Boot, Spring Cloud und Docker

Eberhard Wolff

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.

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

Geschrieben von
Maximilian Kögel
Maximilian Kögel
Dr. Maximilian Kögel ist Geschäftsführer der EclipseSource München GmbH und arbeitet als Senior Software Architect im Bereich Eclipse- und Web-Technologie. Neben seiner Fokussierung auf das Eclipse Modeling Framework und Eclipse RCP ist er auch mit der Entwicklung von Webapplikationen mit AngularJS, Web Components und JSON Schema vertraut. Ein Kernthema seiner Arbeit ist das Erstellen von Modellierungswerkzeugen basierend sowohl auf einem Eclipse- als auch einem Web Technologiestack. Er ist ein aktives Mitglied der Eclipse-Community, regelmäßiger Sprecher auf EclipseCons, Leiter und Committer bei mehreren Eclipse Projekten, u.a. EMFForms und EMF Core und nicht zuletzt Mitglied im Eclipse Architecture Council. Auch außerhalb des Eclipse Ökosystems ist er in Open-Source-Projekten aktiv und leitet z.B. das JSONForms-Projekt zur Entwicklung von Web-Applikationen. Als Berater und Trainer verfügt er über langjährige Erfahrung in der Anwendung und Vermittlung von Expertenwissen rund um Java, Eclipse und Web-Technologien sowie agilen Prozessen.
Jonas Helming
Jonas Helming
Dr. Jonas Helming ist Geschäftsführer der EclipseSource München GmbH sowie Consultant, Trainer und Software Engineer im Bereich Eclipse-Technologie. Seine Schwerpunkte liegen neben Java auf den Technologien Eclipse RCP, Eclipse-Modellierung und Eclipse 4. Weiterhin verfügt er über mehrjährige Erfahrung in der Etablierung und Anwendung von agilen Prozessen. Jonas ist aktives Mitglied der Eclipse-Community, leitet mit der EMF Client Plattform und dem EMFStore zwei bei der Eclipse Foundation gehostete Open-Source-Projekte und ist in einigen weiteren aktiv beteiligt. Als Berater und Trainer verfügt er über mehrjährige Erfahrung in der Vermittlung von Themen rund um Java und Eclipse sowie agilen Prozessen und hält einen Lehrauftrag der Technischen Universität München. Darüber hinaus ist er als Speaker regelmäßig auf Kernkonferenzen wie der JAX oder der EclipseCon. Kontakt: jhelming@eclipsesource.com
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: