Rheinwerk Computing < openbook > Rheinwerk Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.
 
Inhaltsverzeichnis
Vorwort
1 Java ist auch eine Sprache
2 Imperative Sprachkonzepte
3 Klassen und Objekte
4 Der Umgang mit Zeichenketten
5 Eigene Klassen schreiben
6 Objektorientierte Beziehungsfragen
7 Ausnahmen müssen sein
8 Äußere.innere Klassen
9 Besondere Typen der Java SE
10 Generics<T>
11 Lambda-Ausdrücke und funktionale Programmierung
12 Architektur, Design und angewandte Objektorientierung
13 Die Klassenbibliothek
14 Einführung in die nebenläufige Programmierung
15 Einführung in Datenstrukturen und Algorithmen
16 Einführung in grafische Oberflächen
17 Einführung in Dateien und Datenströme
18 Einführung ins Datenbankmanagement mit JDBC
19 Einführung in <XML>
20 Testen mit JUnit
21 Bits und Bytes und Mathematisches
22 Die Werkzeuge des JDK
A Java SE Paketübersicht
Stichwortverzeichnis

Download:
- Beispielprogramme, ca. 20,0 MB
- Übungsaufgaben, ca. 1,8 MB
- Musterlösungen, ca. 0,8 MB

Buch bestellen
Ihre Meinung?

Spacer
<< zurück
Java ist auch eine Insel von Christian Ullenbloom
Das umfassende Handbuch
Buch: Java ist auch eine Insel

Java ist auch eine Insel
Rheinwerk Computing
1306 Seiten, gebunden, 11. Auflage
49,90 Euro, ISBN 978-3-8362-2873-2
Pfeil 20 Testen mit JUnit
Pfeil 20.1 Softwaretests
Pfeil 20.1.1 Vorgehen bei Schreiben von Testfällen
Pfeil 20.2 Das Test-Framework JUnit
Pfeil 20.2.1 Test-Driven-Development und Test-First
Pfeil 20.2.2 Testen, implementieren, testen, implementieren, testen, freuen
Pfeil 20.2.3 JUnit-Tests ausführen
Pfeil 20.2.4 assertXXX(…)-Methoden der Klasse Assert
Pfeil 20.2.5 Matcher-Objekte und Hamcrest
Pfeil 20.2.6 Exceptions testen
Pfeil 20.2.7 Tests ignorieren und Grenzen für Ausführungszeiten festlegen
Pfeil 20.2.8 Mit Methoden der Assume-Klasse Tests abbrechen
Pfeil 20.3 Wie gutes Design das Testen ermöglicht
Pfeil 20.4 Aufbau größerer Testfälle
Pfeil 20.4.1 Fixtures
Pfeil 20.4.2 Sammlungen von Testklassen und Klassenorganisation
Pfeil 20.5 Dummy, Fake, Stub und Mock
Pfeil 20.6 JUnit-Erweiterungen, Testzusätze
Pfeil 20.7 Zum Weiterlesen
 
Zum Seitenanfang

20.3Wie gutes Design das Testen ermöglicht Zur vorigen ÜberschriftZur nächsten Überschrift

Statische Methoden nach dem Muster »Parameter liefert die Eingabe, der Rückgabewert das Ergebnis« sind einfach zu testen. Sie verändern keine Umgebung, und Zustände gibt es keine. Der Testfall muss lediglich die Rückgabe untersuchen, und das ist einfach. Aufwändiger wird es dann schon, wenn Dinge getestet werden sollen, die aufwändige Systemänderungen nach sich ziehen: Wurde eine Datei angelegt? Stehen Dinge in der Datenbank wie gewünscht? Hat der Cluster die Daten auf andere Server gespiegelt? Liefert ein externes Programm die Rückgabe wie erwartet? Gibt eine native Methode tatsächlich das zurück, was sie verspricht, und zieht sie nicht die JVM ins Grab?

Sind Dinge plötzlich nicht mehr testbar, offenbart das im Allgemeinen ein schwaches Design. Häufig liegt es daran, dass eine Klasse zu viele Verantwortlichkeiten hat. Als Beispiel wollen wir uns eine Klasse ansehen, die Visitenkarten im vCard-Format (Dateiendung .vcf) schreibt.[ 252 ] Um den Quellcode schlank zu halten, verzichtet die Klasse VCard auf Setter/Getter.

Listing 20.8com/tutego/insel/junit/util/vdf/v1/VCard.java, VCard

public class VCard
{
public String formattedName;
public String email;
public void export( String filename ) throws IOException
{
StringBuilder result = new StringBuilder( "BEGIN:VCARD\n" );
if ( formattedName != null && ! formattedName.isEmpty() )
result.append( "FN:" ).append( formattedName ).append( "\n" );
if ( email != null && ! email.isEmpty() )
result.append( "EMAIL:" ).append( email ).append( "\n" );
Files.write( Paths.get( filename ),
Collections.singleton( result.append( "END:VCARD" ) ) );
}
}

Wenn die Anwendung etwa die Variable formattedName auf »Powerpuff Girls« setzt und email auf »powerpuff@townsville.com«, dann würde die Methode export(…) eine Datei mit dem folgenden Inhalt erstellen:

BEGIN:VCARD
FN:Powerpuff Girls
EMAIL:powerpuff@townsville.com
END:VCARD

Die Hauptaufgabe der Klasse ist die korrekte Erstellung des Ausgabeformats nach dem vCard-Standard. Die Klasse lässt sich grundsätzlich testen, aber der Test wird nicht besonders schön. Zunächst müssten unterschiedliche vCard-Eigenschaften gesetzt werden, dann wird die vCard in eine Datei geschrieben, anschließend wird die Datei geöffnet, der Inhalt ausgelesen und zum Schluss auf Korrektheit untersucht. Das ist kein sympathischer Weg! Die Klasse VCard ist nicht testorientiert entworfen worden. Warum? Neben der Tatsache, dass so ein Test wegen der Dateizugriffe recht lange dauern könnte, lässt sich prinzipiell festhalten, dass die Methode export(…) zwei Verantwortlichkeiten verbindet, nämlich die Ausgabe in dem speziellen vCard-Format und die Ausgabe in eine Datei. Stünde das Prinzip TDD hinter dem Entwurf, so hätte der Autor die Anteile Format und Ausgabe getrennt. Denn gäbe es eine eigene Methode zur Aufbereitung der Dateien, etwa in einem String, so müsste der Test nur diese Methode aufrufen und bräuchte nicht in einen String zu schreiben. Verbessern wir die Klasse:

Listing 20.9com/tutego/insel/junit/util/vdf/v2/VCard.java, VCard

public class VCard
{
public String formattedName;
public String email;
public void export( Writer out ) throws IOException
{
out.write( toString() );
}
public void export( String filename ) throws IOException
{
try ( Writer writer = Files.newBufferedWriter( Paths.get( filename ) ) ) {
export( writer );
}
}
@Override
public String toString()
{
StringBuilder result = new StringBuilder( "BEGIN:VCARD\n" );
if ( formattedName != null && ! formattedName.isEmpty() )
result.append( "FN:" ).append( formattedName ).append( "\n" );
if ( email != null && ! email.isEmpty() )
result.append( "EMAIL:" ).append( email ).append( "\n" );
return result.append( "END:VCARD" ).toString();
}
}

Diese Variante bringt gleich zwei Verbesserungen mit sich:

  1. Die Methode toString() liefert nun den nach dem vCard-Standard aufbereiteten String. Der Test muss nun lediglich ein VCard-Objekt aufbauen, die Variablen setzen, toString() aufrufen und ohne Dateioperationen den String auf Korrektheit testen. Für den Client ändert sich die API aber nicht; er schreibt weiterhin export(…).

  2. Direkt in Dateien zu schreiben ist nicht mehr so richtig zeitgemäß. Das berücksichtigt die Klasse und bietet eine überladene Version von export(…) mit einem allgemeinen Writer. Sollte dann etwa eine vCard über das Netzwerk verschickt werden, ist das kein Problem, und es muss lediglich ein passender Writer für das Netzwerkziel übergeben werden. Vorher wäre das sehr umständlich gewesen: Datei erzeugen, Datei auslesen, String verschicken.

Im Endeffekt ist der Gewinn groß. Der Test ist performanter, und das Design führt zu besserem Quellcode: eine Win-Win-Situation.

Der gewählte Ansatz zeigt, wie bei Implementierungen zu verfahren ist, die insbesondere mit externen Ressourcen sprechen. Diese gilt es, so weit wie möglich herauszuziehen, wenn nötig auch in einem neuen Typ, der dann als Testimplementierung injiziert werden kann.

 


Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.

>> Zum Feedback-Formular
<< zurück
 Zum Katalog
Zum Katalog: Java ist auch eine Insel Java ist auch eine Insel
Jetzt bestellen

 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Java SE 8 Standard-Bibliothek
Java SE 8 Standard-Bibliothek


Zum Katalog: Professionell entwickeln mit Java EE 7
Professionell entwickeln mit Java EE 7


Zum Katalog: Schrödinger programmiert Java
Schrödinger programmiert Java


Zum Katalog: Einführung in Java
Einführung in Java


Zum Katalog: Programmieren lernen mit Java
Programmieren lernen mit Java


Zum Katalog: Apps entwickeln für Android 5
Apps entwickeln für Android 5


Zum Katalog: Apps entwickeln mit Android Studio
Apps entwickeln mit Android Studio


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo

 
 


Copyright © Rheinwerk Verlag GmbH 2016
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

 
Nutzungsbestimmungen | Datenschutz | Impressum

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de