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

21Testen mit JUnit Zur vorigen ÜberschriftZur nächsten Überschrift

»Es gibt keinen Grund, warum man einen Computer zu Hause haben sollte.«

– Ken Olson, Präsident der Digital Equipment Corp, 1977

 

Zum Seitenanfang

21.1Softwaretests Zur vorigen ÜberschriftZur nächsten Überschrift

Um möglichst viel Vertrauen in die eigene Codebasis zu bekommen, bieten sich Softwaretests an. Tests sind kleine Programme, die ohne Benutzerkontrolle automatisch über die Quellcodebasis laufen und anhand von Regeln zeigen, dass vom Kunden gewünschte Teile sich so verhalten wie spezifiziert. (Die Abwesenheit von Fehlern kann eine Software natürlich nicht zeigen, aber immer zeigt ein Testfall, dass das Programm die Vorgaben aus der Spezifikation erfüllt.)

Obwohl Softwaretests extrem wichtig sind, sind sie unter Softwareentwicklern nicht unbedingt populär. Das liegt unter anderem daran, dass sie natürlich etwas Zeit kosten, die neben der tatsächlichen Entwicklung aufgewendet werden muss. Wenn dann die eigentliche Software geändert wird, müssen auch die Testfälle oftmals mit angefasst werden, sodass es gleich zwei Baustellen gibt. Und da Entwickler ein Feature eigentlich immer gestern fertigstellen sollten, fallen die Tests gerne unter den Tisch. Ein weiterer Grund ist, dass einige Entwickler sich für unfehlbare Kodierungsgötter halten, die jeden Programmcode (nach ein paar Stunden Debuggen) für absolut korrekt, performant und wohlduftend halten.

Wie lässt sich diese skeptische Gruppe nun überzeugen, doch Tests zu schreiben? Ein großer Vorteil von automatisierten Tests ist die Eigenschaft, dass bei großen Änderungen der Quellcodebasis (Refactoring) die Testfälle automatisch sagen, ob alles korrekt verändert wurde. Denn wenn nach dem Refactoring, etwa einer Performance-Optimierung, die Tests einen Fehler melden, ist wohl etwas kaputtoptimiert worden. Da Software einer permanenten Änderung unterliegt und nie fertig ist, sollte das Argument eigentlich schon ausreichen, denn wenn eine Software eine gewisse Größe erreicht hat, ist nicht absehbar, welche Auswirkungen Änderungen an der Quellcodebasis nach sich ziehen. Dazu kommt ein weiterer Grund, sich mit Tests zu beschäftigen: Es ist der positive Nebeneffekt, dass die erzeugte Software vom Design deutlich besser ist, denn testbare Software zu schreiben ist knifflig, führt aber fast zwangsläufig zu besserem Design. Und ein besseres Design ist immer erstrebenswert, denn es erhöht die Verständlichkeit und erleichtert die spätere Anpassung der Software.

 

Zum Seitenanfang

21.1.1Vorgehen beim Schreiben von Testfällen Zur vorigen ÜberschriftZur nächsten Überschrift

Die Fokussierung bei Softwaretests liegt auf zwei Attributen: automatisch und wiederholbar. Dazu ist eine Bibliothek nötig, die zwei Dinge unterstützen muss:

  • Testfälle sehen immer gleich aus und bestehen aus drei Schritten. Zunächst wird ein Szenario aufgebaut, dann wird die zu testende Methode oder Methodenkombination aufgerufen, und zum Schluss wird mit der spezifischen API vom Test-Framework geschaut, ob das ausgeführte Programm genau das gewünschte Verhalten gebracht hat. Das übernehmen eine Art »Stimmt-es-dass«-Methoden, die den gewünschten Zustand mit dem tatsächlichen abgleichen und bei einem Konflikt eine Ausnahme auslösen.

  • Das Test-Framework muss die Tests laufen lassen und im Fehlerfall eine Meldung geben; dieser Teil nennt sich Test-Runner.

Wir werden uns im Folgenden auf so genannte Unit-Tests beschränken. Das sind Tests, die einzelne Bausteine (engl. units) testen. Daneben gibt es andere Tests, wie Lasttests, Performance-Tests oder Integrationstests, die aber im Folgenden keine große Rolle spielen.

 


Ihr Kommentar

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

>> Zum Feedback-Formular
<< zurück

 

 


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