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 Komponenten, JavaBeans und Module
14 Die Klassenbibliothek
15 Einführung in die nebenläufige Programmierung
16 Einführung in Datenstrukturen und Algorithmen
17 Einführung in grafische Oberflächen
18 Einführung in Dateien und Datenströme
19 Einführung ins Datenbankmanagement mit JDBC
20 Einführung in <XML>
21 Testen mit JUnit
22 Bits und Bytes und Mathematisches
23 Die Werkzeuge des JDK
A Java SE-Paketübersicht
Stichwortverzeichnis


Download:

- Beispielprogramme, ca. 35,4 MB


Buch bestellen
Ihre Meinung?



Spacer
<< zurück
Java ist auch eine Insel von Christian Ullenboom

Einführung, Ausbildung, Praxis
Buch: Java ist auch eine Insel


Java ist auch eine Insel

Pfeil 21 Testen mit JUnit
Pfeil 21.1 Softwaretests
Pfeil 21.1.1 Vorgehen beim Schreiben von Testfällen
Pfeil 21.2 Das Test-Framework JUnit
Pfeil 21.2.1 Test-Driven Development und Test-First
Pfeil 21.2.2 Testen, implementieren, testen, implementieren, testen, freuen
Pfeil 21.2.3 JUnit-Tests ausführen
Pfeil 21.2.4 assertXXX(…)-Methoden der Klasse Assert
Pfeil 21.2.5 Matcher-Objekte und Hamcrest
Pfeil 21.2.6 Exceptions testen
Pfeil 21.2.7 Tests ignorieren und Grenzen für Ausführungszeiten festlegen
Pfeil 21.2.8 Mit Methoden der Assume-Klasse Tests abbrechen
Pfeil 21.3 Wie gutes Design das Testen ermöglicht
Pfeil 21.4 Aufbau größerer Testfälle
Pfeil 21.4.1 Fixtures
Pfeil 21.4.2 Sammlungen von Testklassen und Klassenorganisation
Pfeil 21.5 Dummy, Fake, Stub und Mock
Pfeil 21.6 JUnit-Erweiterungen, Testzusätze
Pfeil 21.7 Zum Weiterlesen
 

Zum Seitenanfang

21.5Dummy, Fake, Stub und Mock Zur vorigen ÜberschriftZur nächsten Überschrift

Gute objektorientiert entworfene Systeme zeichnen sich dadurch aus, dass es eine hohe Interaktion mit anderen Objekten gibt. Idealerweise zerlegt eine Klasse ein Problem nur bis zu dem Punkt, an dem es sich einer anderen Klasse bedienen kann, die dieses einfachere Problem löst. Schwierig wird es, wenn eine eigene Klasse auf eine andere komplexe Klasse zurückgreift und das Objekt nur dann sinnvoll arbeitet, wenn das referenzierte Objekt da ist und irgendwie sinnvoll antwortet. Diese Abhängigkeit ist ungünstig, denn das Ziel eines guten Tests besteht ja darin, lokal zu sein, also die eigentliche Klasse zu testen und nicht alle referenzierten Klassen um sie herum gleich mit.

In der Praxis begegnen uns drei Hilfskonstrukte, die die Lokalität von Tests ermöglichen:

  • Fake-Objekte: Sie sind eine gültige Implementierung einer Schnittstelle, haben aber kein Verhalten, sondern der Rumpf der Methoden ist quasi leer. Sie gibt es nur für die Testfälle. Wenn ein Service etwa auf einen anderen Service zurückgreift, um eine E-Mail mit der einzigen angebotenen Methode void send(String msg, String receiver) zu versenden, kann ein Fake-Objekt diesen E-Mail-Service »implementieren«, aber es muss dazu überhaupt kein Verhalten nachbilden.

  • Stub-Objekte: Stub-Objekte implementieren ein bestimmtes Protokoll, sodass sie für den Testfall immer die gleichen Antworten geben können. Wenn etwa der E-Mail-Service eine Methode isTransmitted() anbietet, so kann der Stub immer true liefern. Oder ein Stub-Repository liefert statt Kunden aus der Datenbank immer die gleichen zehn vorgefertigten Kunden. Oder man wartet nicht, bis ein langsamer Web-Service-Aufruf die aktuellen Wetterdaten liefert, sondern der Stub gibt vorgefertigte ab. Stubs sind auch praktisch, wenn zum Beispiel eine GUI-Anwendung programmiert wird, die statt echter Datenbankdaten erst einmal mit den Stubs entwickelt wird und so die Demodaten anzeigt. Wenn ein Team die GUI baut und ein anderes Team den Service, so können beide Gruppen unabhängig arbeiten, und das GUI-Team muss nicht erst auf die Implementierung warten.

  • Mock-Objekte: Mock-Objekte sind noch funktionsreichhaltiger als Stubs und bilden auch komplexe Interaktionen ab. In der Regel werden Mock-Objekte durch eine Bibliothek wie mockito (http://mockito.org) oder EasyMock (http://easymock.org) »aufgeladen« – sie liefern also nicht wie Stubs immer das gleiche Ergebnis – und zeigen dann das gewünschte Verhalten.

Diese drei Typen können wir unter dem Oberbegriff Dummy-Objekt zusammenfassen. Grundsätzlich gilt bei den vier Begriffen aber, dass sie von Autoren nicht einheitlich verwendet werden.[ 257 ](Die Seite http://xunitpatterns.com/Mocks,%20Fakes,%20Stubs%20and%20Dummies.html stellt einige Autoren mit ihrer Begriffsnutzung vor. )

 


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 ist auch eine Insel

Java ist auch eine Insel




Zum Katalog: Java SE 9-Standard-Bibliothek

Java SE 9-Standard-Bibliothek




Zum Katalog: Professionell entwickeln mit Java EE 8

Professionell entwickeln mit Java EE 8




Zum Katalog: Entwurfsmuster

Entwurfsmuster




Zum Katalog: IT-Projektmanagement

IT-Projektmanagement




 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich

InfoInfo



 

 


Copyright © Rheinwerk Verlag GmbH 2017

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.

 

[Rheinwerk Computing]



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