© Excellent backgrounds/Shutterstock.com
Java Magazin
Mit Testbench die Testabdeckung erhöhen

Mutations aufspüren

JUnit ist im Bereich des Test-driven Developments für den Java-Entwickler ein bekanntes Werkzeug. Es hat sich durchgesetzt, zusätzlich die Testabdeckung (Code Coverage) zu messen. Aber was genau bedeutet das? Eine Testabdeckung von rund 75 Prozent auf Zeilenebene ist sehr gut und kann schon als Grundlage dienen. Aber wie aussagekräftig ist diese Zahl?

Sven Ruppert


Schauen wir uns ein Vaadin-Projekt an und untersuchen es darauf hin, wie und wo die Vorteile von Mutation Testing im Vergleich zu der klassischen Line Coverage zu finden sind. Das Projekt besteht aus nur wenigen Klassen, sodass es leicht sein wird, anhand dieser Quelltexte eigene Experimente durchzuführen. Dennoch ist eine gewisse Komplexität und Menge an Zeilen Quelltext notwendig, um die Effekte nachvollziehbar darzustellen. Die Anwendung besteht zu Beginn aus vier Klassen:

Customer: reines PoJoCustomerStatus: Enumeration mit dem Status, die ein Customer einnehmen kannCustomerService: Backend der AnwendungMyUI: UI der Anwendung und ein Vaadin Servlet

Für den Anwender sieht das so aus: Zuerst erscheint eine Tabelle mit den Datensätzen. Diese lässt sich filtern, indem in das obere linke Textfeld ein Suchbegriff eingegeben wird (Abb. 1).

Abb. 1: Startoberfläche der Anwendung

Wird ein Element in der Tabelle selektiert, erscheint auf der rechten Seite eine Maske, in der sich die Entität bearbeiten oder löschen lässt (Abb. 2).

Abb. 2: Entität bearbeiten oder löschen

jUnit4 und TestBench

Um diese Anwendung zu testen, kommt TestBench zum Einsatz. Wir definieren die notwendigen Abhängigkeiten in der pom.xml definiert (Listing 1).

Listing 1: Abhängigkeiten definierenxml com.vaadin vaadin-testbench test org.seleniumhq.selenium selenium-java test

Die Grundlagen zu TestBench werden wir nicht besprechen, die offizielle Dokumentation hilft an dieser Stelle weiter [1]. Um bequem auf die Elemente des UI zugreifen zu können und die Tests zu formulieren, erstellen wir zuerst eine Klasse AddressBook. Dort realisieren wir das Pattern PageObject. Damit der Zugriff auf den Webdriver einfach zu handhaben ist, wird die Klasse AdressBook von der Klasse TestbenchTestCase abgeleitet (Listing 2).

Listing 2: „AdressBook“public class AddressBook extends TestBenchTestCase {  public AddressBook(WebDriver driver) { setDriver(driver); }  public String getLastNameAtIndex(int index) { return $(GridElement.class).first() .getCell(index , 1).getText(); }  public String getFirstNameAtIndex(int index) { return $(GridElement.class).first() .getCell(index , 0).getText(); }  public EntryForm selectEntryAtIndex(int index) { $(GridElement...

Java Magazin
Mit Testbench die Testabdeckung erhöhen

Mutations aufspüren

JUnit ist im Bereich des Test-driven Developments für den Java-Entwickler ein bekanntes Werkzeug. Es hat sich durchgesetzt, zusätzlich die Testabdeckung (Code Coverage) zu messen. Aber was genau bedeutet das? Eine Testabdeckung von rund 75 Prozent auf Zeilenebene ist sehr gut und kann schon als Grundlage dienen. Aber wie aussagekräftig ist diese Zahl?

Sven Ruppert


Schauen wir uns ein Vaadin-Projekt an und untersuchen es darauf hin, wie und wo die Vorteile von Mutation Testing im Vergleich zu der klassischen Line Coverage zu finden sind. Das Projekt besteht aus nur wenigen Klassen, sodass es leicht sein wird, anhand dieser Quelltexte eigene Experimente durchzuführen. Dennoch ist eine gewisse Komplexität und Menge an Zeilen Quelltext notwendig, um die Effekte nachvollziehbar darzustellen. Die Anwendung besteht zu Beginn aus vier Klassen:

Customer: reines PoJoCustomerStatus: Enumeration mit dem Status, die ein Customer einnehmen kannCustomerService: Backend der AnwendungMyUI: UI der Anwendung und ein Vaadin Servlet

Für den Anwender sieht das so aus: Zuerst erscheint eine Tabelle mit den Datensätzen. Diese lässt sich filtern, indem in das obere linke Textfeld ein Suchbegriff eingegeben wird (Abb. 1).

Abb. 1: Startoberfläche der Anwendung

Wird ein Element in der Tabelle selektiert, erscheint auf der rechten Seite eine Maske, in der sich die Entität bearbeiten oder löschen lässt (Abb. 2).

Abb. 2: Entität bearbeiten oder löschen

jUnit4 und TestBench

Um diese Anwendung zu testen, kommt TestBench zum Einsatz. Wir definieren die notwendigen Abhängigkeiten in der pom.xml definiert (Listing 1).

Listing 1: Abhängigkeiten definierenxml com.vaadin vaadin-testbench test org.seleniumhq.selenium selenium-java test

Die Grundlagen zu TestBench werden wir nicht besprechen, die offizielle Dokumentation hilft an dieser Stelle weiter [1]. Um bequem auf die Elemente des UI zugreifen zu können und die Tests zu formulieren, erstellen wir zuerst eine Klasse AddressBook. Dort realisieren wir das Pattern PageObject. Damit der Zugriff auf den Webdriver einfach zu handhaben ist, wird die Klasse AdressBook von der Klasse TestbenchTestCase abgeleitet (Listing 2).

Listing 2: „AdressBook“public class AddressBook extends TestBenchTestCase {  public AddressBook(WebDriver driver) { setDriver(driver); }  public String getLastNameAtIndex(int index) { return $(GridElement.class).first() .getCell(index , 1).getText(); }  public String getFirstNameAtIndex(int index) { return $(GridElement.class).first() .getCell(index , 0).getText(); }  public EntryForm selectEntryAtIndex(int index) { $(GridElement...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang