Mit der Basismetrik Zeile für Zeile zu besseren Ergebnissen
Java-Testabdeckung Teil 2: Line Coverage
Von: Sven Ruppert
In dieser Reihe von Blogbeiträgen werden wir uns eingehend mit den verschiedenen Aspekten der Testabdeckung befassen und verschiedene Techniken und Tools untersuchen, die Entwicklern dabei helfen, qualitativ hochwertige Software zu erstellen. In diesem Beitrag untersuchen wir die zeilenbasierte Testabdeckung.
Die Zeilenabdeckung
Die Zeilenabdeckung ist eine Code-Abdeckungsmetrik, die misst, ob jede Zeile Quellcode eines Programms während des Tests ausgeführt wurde. Auch in Java zeigt die Zeilenabdeckung uns Entwicklern, wie gründlich unsere Tests den Code ausführen, indem sie angibt, welche Zeilen getestet wurden und welche nicht. Wir wollen uns die Zeilenabdeckung anhand von Java genauer ansehen.
Schlüsselkonzepte der Zeilenabdeckung
Definition
Die Zeilenabdeckung misst, ob jede Codezeile während des Tests mindestens einmal ausgeführt wurde.
Bedeutung
Fehlererkennung: Hilft bei der Identifizierung ungetesteter Teile des Codes, die möglicherweise Fehler enthalten.
Codequalität: Stellt sicher, dass alle Teile des Codes getestet werden, was zu einer insgesamt besseren Codequalität führt.
Wartung: Hilft bei der Pflege des Codes, indem sichergestellt wird, dass Änderungen und neue Ergänzungen getestet werden.
Tools zum Messen der Zeilenabdeckung in Java
JaCoCo (Java-Code-Abdeckung): Eine weit verbreitete Open-Source-Bibliothek zur Messung der Codeabdeckung in Java-Projekten.
Emma: Ein weiteres beliebtes Tool, das jedoch größtenteils von JaCoCo abgelöst wurde.
Cobertura: Ein älteres Code-Coverage-Tool, das in einigen Projekten immer noch verwendet wird.
EclEmma: Ein Eclipse-Plugin für JaCoCo, das die Visualisierung der Berichterstattung direkt in der IDE vereinfacht.
So funktioniert Zeilenabdeckung
Tools wie JaCoCo instrumentieren den Bytecode eines Java-Programms, um an verschiedenen Stellen Sonden einzufügen. Diese sammeln Daten darüber, welche Codezeilen während des Testlaufs ausgeführt werden. Sobald der Code instrumentiert ist, werden die Tests ausgeführt. Während die Tests ausgeführt werden, sammeln die Sonden unterschiedliche Ausführungsdaten für jede Codezeile. Nach Abschluss eines Tests generiert das Coverage-Tool einen Bericht, der zeigt, welche Codezeilen ausgeführt wurden. Dieser Bericht enthält häufig visuelle Indikatoren (z. B. Farbcodierung), um abgedeckte (ausgeführte) und nicht abgedeckte (nicht ausgeführte) Linien hervorzuheben.
Beispiel-Workflow mit JaCoCo
Für ein Maven-Projekt fügen wir das JaCoCo-Plugin zur Datei pom.xml hinzu:
<build>
<plugins>
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.8.8</version>
<executions>
<execution>
<goals>
<goal>prepare-agent</goal>
</goals>
</execution>
<execution>
<id>report</id>
<phase>test</phase>
<goals>
<goal>report</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>- Führe die Tests mit Maven aus:
mvn clean test - Generiere nach dem Ausführen der Tests den Abdeckungsbericht: `mvn jacoco:bericht`
Der Bericht wird normalerweise im Verzeichnis target/site/jacoco generiert. Um den detaillierten Abdeckungsbericht anzuzeigen, öffne die Datei index.html in einem Webbrowser.
Berichte zur Zeilenabdeckung interpretieren
Der Abdeckungsprozentsatz beschreibt den Anteil der ausgeführten Zeilen an der Gesamtzahl der Zeilen. Normalerweise weist eine grüne Hervorhebung auf abgedeckte Zeilen hin, während nicht abgedeckte Zeilen rot hervorgehoben werden. Berichte können zusätzliche Messwerte wie die Anzahl der abgedeckten und verpassten Zeilen, Verzweigungen und Methoden enthalten.
Empfohlene Vorgehensweise
Du solltest nach der größtmöglichen Abdeckung für dein Projekt streben, um die maximale Zuverlässigkeit deines Codes zu gewährleisten – eine hundertprozentige Abdeckung ist ideal. Stelle vor allem sicher, dass die kritischsten und komplexesten Teile deines Codes umfassend abgedeckt sind. Im Rahmen deiner CI/CD-Pipeline solltest du regelmäßig Abdeckungsberichte ausführen, um Regressionen zu erkennen und sicherzustellen, dass neuer Code ausreichend getestet wird. Die Zeilenabdeckung ist nur ein Aspekt des Testens. Für eine umfassende Abdeckung benötigst du zusätzliche Techniken wie Unit-, Integrations- und manuelle Tests.
Einschränkungen
Eine hohe Zeilenabdeckung garantiert noch nicht das Erkennen von Fehlern. Es ist möglich, dass Tests alle Zeilen abdecken, dabei die Logik jedoch nicht effektiv testen. Das bloße Streben nach hohen Abdeckungszahlen kann dazu führen, dass oberflächliche Tests geschrieben werden, die das Verhalten des Codes nicht gründlich validieren.
Die Zeilenabdeckung ist eine wertvolle Metrik zur Beurteilung der Gründlichkeit deiner Tests in Java-Projekten. Die Verwendung von Tools wie JaCoCo und die Befolgung von Best-Practices stellen sicher, dass dein Code gut getestet ist und hohe Qualitätsstandards einhält. Die Zeilenabdeckung sollte jedoch immer als Teil einer umfassenderen Teststrategie verwendet werden, um die besten Ergebnisse zu erzielen.
Über den Autor: Sven Ruppert
Sven programmiert seit 1996 Java in Industrieprojekten, seit über 15 Jahren weltweit Java in Branchen wie Automobil, Raumfahrt, Versicherungen, Banken, der UNO und der Weltbank. Seit zehn Jahren ist er als Sprecher auf Konferenzen und Community-Events in Ländern von Amerika bis Neuseeland. Er hat als Developer Advocate für JFrog und Vaadin gearbeitet und schreibt regelmäßig Artikel für IT-Magazine und Technologieportale.
Diese Beiträge könnten dich auch interessieren:
Der Beitrag Etwas weniger magisch, aber leichter zu lernen erschien zuerst auf heise academy Blog.
]]>Der Beitrag Frameworks – braucht’s die eigentlich noch? erschien zuerst auf heise academy Blog.
]]>Frameworks – braucht’s die eigentlich noch?
Von Brennpunkten in der IT-Landschaft und neuen Interpretationen alter Probleme
Von: Katja Potensky
Ich bin zwar nicht bekannt dafür, aus der Bibel zu zitieren, aber hin und wieder passt eine Passage einfach:
Es gibt nichts neues unter der Sonne. – Prediger 1,9
Daran fühlte ich mich letzte Woche erinnert bei einer Diskussion zur Frage, ob es Frameworks noch brauche. Du kannst dir sicher vorstellen, wie lebhaft solch ein Diskurs geführt wird. In den folgenden Absätzen möchte ich die verschiedenen Blickwinkel sowie meine Two Cents zum Thema Frameworks mit euch teilen.
Was ist überhaupt ein Framework?
Ein Framework ist eine Sammlung von Software mit einer zugehörigen Sammlung an Kompromissen. – Peter Kröner
Diese Definition kam zu Beginn der angesprochenen Diskussion auf und ich halte sie für die erste sinnvolle überhaupt. Denn sie deutet bereits darauf hin, dass wir es hier nicht mit einer rein technischen Fragestellung zu tun haben. Dennoch möchte ich den technischen Blickwinkel als Ausgangspunkt wählen.
Worin liegt der technische Bedarf?
Gibt es einen technischen Bedarf für C oder Java? Warum programmieren wir nicht alle einfach Assembler? Der Bedarf richtet sich nicht nur nach den Zielen, sondern auch nach den Aufwänden. Man wollte irgendwann nicht mehr in Assembler programmieren, also haben schlaue Menschen begonnen, die typischen Aufgaben zu abstrahieren und irgendwann kam unter anderem C dabei raus. Später hat sich herausgestellt, dass man auch in C viele wiederkehrende Aufgaben lösen musste, also hat sich über ein paar Umwege Java ergeben. Du siehst also, das Ganze ist ein iterativer Prozess.
Auf solchem Wege wurde auch die Aufgabe, ein buntes Kästchen im Browser zu bauen, in das man etwas reintippen kann, immer mehr abstrahiert. Diese Abstraktionen wurden zu den Frameworks, die wir heute kennen. Mittlerweile sind wiederum viele bis alle typischen Aufgaben zum Erstellen einer BLOBA (Boring Line-of-Business Application), bei denen ein Framework in den letzten zehn Jahren geholfen hat, durch Erweiterungen der Webstandards ohne größere oder sogar mit weniger Problemen umsetzbar.
Ich rate hier dringend dazu, auf MDN die Liste der HTML-Elemente alle paar Jahre durchzugehen, genauso wie die Liste der Web-APIs. Dialoge, Dropdowns oder auch die meisten Validierungen sollte man im Jahr 2024 wirklich nicht mehr mit einer teuren Component Library umsetzen.
Auch wenn es um das Thema Bundling und CI/CD geht, lohnt sich ein Blick über den Tellerrand. Gerade hier führt der Einsatz schwergewichtiger Lösungen gerne zu unvorhergesehenen Problemen.
Tipp: „Code is a liability, not an asset“ gilt auch für jenen Code, den wir nicht selbst schreiben. Wenn sich Abhängigkeiten ungünstig verhalten, ist meistens das einzige, was wir heutzutage tun können, einen Bug Report zu erstellen und die Ohren steif zu halten. Oder hast du schon mal probiert, eine geforkte Version von Angular auszurollen? ;)
Aber gut, dieses Argument schaut auf die bisherigen Umstände. Was ist, wenn wir in die Zukunft blicken?
Der Blick nach vorne
Gehen wir rein theoretisch davon aus, dass Angular, React, Vue etc. ihre Repositories und Packages löschen und wir alle unsere BLOBAs mit HTML und gezielt eingesetztem Javascript bauen.
Einer der Trends unserer Zeit ist ganz klar KI, man kann heutzutage im Browser mittels WebGPU Zugriff auf die GPU erlangen. Jetzt wäre es nicht allzu weit hergeholt, dass für diverse Use-Cases auf vielen Websites Chatbots implementiert werden sollen. Und zwar auf so vielen, dass es sich zur Vereinfachung des Anwendungsfalls auszahlt, Libraries darum herum zu schreiben. Vielleicht kommen auch Bezahlmöglichkeiten mittels Payment Request API dazu und ein paar andere Dinge, die so typisch werden, dass wir wiederum eine Reihe von Libraries unter der Annahme von gewissen Kompromissen auf eine spezifische Art und Weise verbinden, die wir gut finden… und prompt haben wir unser nächstes Framework geschaffen.
Wir können also davon ausgehen, dass es immer (neue) Frameworks geben wird. Denn so wunderbar die Webstandards sind, sie können und sollen eben nicht meinungsgetrieben sein. Selbst die Gamepad API existiert, weil es ausreichend Bedarf dafür gab und nicht umgekehrt. Neue Bedürfnisse sollten nicht durch Webstandards verprobt werden, sondern durch Libraries und Frameworks. Aber wer würde solche neuen Frameworks wohl verwenden?
„Apes together strong“
Wie viele Frameworks, die uns geholfen haben Formulare und Seitennavigationen zu bauen, gibt es wohl?
2011 habe ich einige JS-Files geschrieben, die mittels beliebiger Attribute an HTML-Elementen diese Elemente um eine beliebige Funktionalität erweitern können. Das weiß kaum jemand, da ich diese Idee zum einen nicht verbreitet habe. Zum anderen wurde ich ein paar Wochen später mit AngularJS konfrontiert und dachte mir: „Hey, die Idee hatte schon jemand.“ Also habe ich meinen eigenen Code verworfen und stattdessen AngularJS eingesetzt, weil es zum damaligen Zeitpunkt genau das tat, was ich zum damaligen Zeitpunkt brauchte. Es gibt Ideen, um die Menschen sich versammeln, und das hat gleich mehrere Auswirkungen.
Brennpunkte
Egal ob man diesen Ansatz gut findet oder nicht, egal ob man React oder Angular mag – durch die Existenz von Frameworks bilden sich gewissermaßen Brennpunkte in der IT-Landschaft. Orte, an denen Menschen zusammen kommen, ihre Ideen einbringen und Richtlinien rund um die vermeintlich korrekte (idiomatische) Verwendung der jeweiligen Lösung erarbeiten.
Diese Richtlinien mögen uns gefallen oder nicht, sie ermöglichen einen effizienteren Austausch in Projekten und ein schnelleres Onboarding von neuen Personen. Durch die kontinuierliche Anwendung dieser Richtlinien werden sie innerhalb gewisser Grenzen laufend verbessert. Aber was, wenn man an diese Grenzen stößt und sich nicht damit abfinden will?
Dissonanz
Zu Deutsch: Unstimmigkeit, Missklang. Stell dir vor, du kannst nicht damit leben, dass AngularJS die Änderungen an Objekten periodisch und recht teuer auf den Bildschirm bringt. Ganz egal, wie viel optimiert wird, hier ist das grundlegende Konzept das Problem und irgendwann stößt man an die Grenzen des technisch Möglichen.
Wenn das ein Knockout-Kriterium ist, muss man besagten Brennpunkt verlassen, zurück ans Zeichenbrett und von Null auf neue Wege gehen. Das mag erst mal unglaublich schwer klingen, aber man hat einige gewaltige Vorteile dabei: Man weiß, was das Problem ist, wie man es nicht löst und was die Erwartungshaltungen sind.
Und nach ein paar Monaten Hin und Her, Recherche und Trial-and-Error hat man dann wahrscheinlich einen Weg, um den Anwendungsfall, an dem die vorige Idee gebrochen ist, besser umzusetzen. Um es mit den Worten von Soichiro Honda zu sagen:
„Racing improves the breed.“
Die Frage ist dann eher, ob das, was wir jetzt besser machen können, die Verbesserung überhaupt verdient hat.
Ein alter Hut?
Sind Frameworks also bloß immer neue Interpretationen von ewig alten Problemen? Nun, irgendwie schon, aber irgendwie auch nicht. Mir fällt hierzu eine Anekdote ein. Ich fand Liebeslieder immer kitschig und sinnlos, bis ich mal einen Musiker bei einer Show sagen hörte: „Natürlich wurden die Worte ‚I love you‘ schon tausende Male vertextet, natürlich ist jedes Liebeslied irgendwie gleich. Aber vielleicht, nur vielleicht, wurde es ja noch nicht mit den selben Gefühlen gesungen, die du dabei spürst. Und selbst wenn, warum sollte dich das davon abhalten, ‚I love you‘ zu sagen?“
Vielleicht können wir darüber hinweg sehen, welches Framework technisch besonders ausgefeilt ist, und einfach das verwenden, das am besten zur aktuellen Situation passt. Und wenn die aktuelle Situation bloß erfordert, eine Reihe von Formularen zu erstellen, könnte man ‚I love you‘ mal ganz ohne jegliche Schnörkel sagen. Denn der größte Brennpunkt in der IT-Landschaft sind immer noch die Webstandards.
Über die Autorin: Katja Potensky
Katja ist Software Engineer bei adesso und seit 2012 in einem professionellen Setting tätig. Sie lässt sich nicht auf einzelne Aspekte eines Systems limitieren, und hat von daher schon eine Vielzahl an Projekten in unterschiedlichsten Rollen und Teamgrößen umgesetzt. Aus der Arbeit mit unterschiedlichsten Webtechnologien hat sich ein fundierter Anspruch an Codequalität und korrektes Programmverhalten entwickelt den sie auch weitergeben möchte. Sie brennt für Code der leicht zu lesen ist und nicht bedingt die halbe Codebase im Kopf zu behalten um zu verstehen was “da gerade passiert”.
