Testgetriebene Entwicklung
mit JUnit und FIT
Frank Westphal
Testgetriebene Entwicklung
mit JUnit & FIT:
Wie Software änderbar bleibt
dpunkt.verlag
346 Seiten
November 2005
ISBN 3-89864-220-8
Bei Amazon ansehen
Beschreibung
Testgetriebene Entwicklung geht von einem fehlschlagenden Test aus. Software wird in kleinen sicheren Schritten entwickelt, die abwechselnd darauf abzielen, eine neue Anforderung zu implementieren (den fehlschlagenden Test also zu erfüllen) und das Design zu verbessern (und dabei weiterhin alle Tests zu bestehen).
- Wenn frühes und häufiges Testen wichtig ist, warum schreiben wir nicht für jedes neue Feature zuerst einen automatisierten Test? So können wir während der Entwicklung jederzeit unsere Tests ausführen und lernen, ob unser Code wie gewünscht funktioniert.
- Wenn Design wichtig ist, warum investieren wir dann nicht Tag für Tag darin? So können wir dafür sorgen, dass es möglichst einfach bleibt und nicht mit der Zeit zunehmend degeneriert.
- Wenn Anforderungsdefinition wichtig ist, warum ermöglichen wir unseren Kunden dann nicht, in einem ausführbaren Anforderungsdokument Testfälle für konkrete Anwendungsbeispiele zu spezifizieren? So können wir dokumentieren, welche Funktionalität tatsächlich gefordert ist, und anschließend verifizieren, ob die Erwartungen des Kunden erfüllt werden.
Das Buch führt mit praktischen Beispielen in die Testgetriebene Entwicklung mit den Open-Source-Werkzeugen JUnit und FIT ein.
Frank Westphal has turned his extensive experience in using and teaching developer testing with JUnit and FIT into a thorough and usable guide for programmers and testers, including the first published guide to JUnit 4.
What I was most struck by in reading this book was the combination of philosophical background and detailed, practical advice.
– Kent Beck, Three Rivers Institute
Amazon-Rezensionen
ganz aus dem häuschen
– Thomas Steinbach
Warum sind wir darauf nicht schon eher gekommen?
– H. Mausolf
Grandios !!
– Bernd Will
Lockere Lektüre für flotte Erfolge
– Gernot Starke
Motivation für die Praxis
– Frankmartin Wiethüchter
Seit langem kein Buch mehr so schnell durchgearbeitet!
– Ulrich Storck
Rundum gelungen
– Jens Uwe Pipka
Übers Entwickeln und Entwerfen - auf testgetriebene Art
– Christoph Steindl
Ideal für professionelle Softwareentwickler
– Dierk König
Testen als Mittel zum Zweck
– Stefan Roock
Buchbesprechungen
- Amazon.de Kundenrezensionen
- Alexander Hansen
- Dirk Frischalowski (Java Magazin 3.2006)
- Horst Franzke
- Stefan Roock
Inhaltsverzeichnis
Geleitwort von Johannes Link (PDF)
Kapitel 1: Einleitung (PDF)
- Was ist Testgetriebene Entwicklung?
- Warum Testgetriebene Entwicklung?
- Über dieses Buch
- Merci beaucoup
Kapitel 2: Testgetriebene Entwicklung, über die Schulter geschaut
- Eine Programmierepisode
- Testgetriebenes Programmieren
- Möglichst einfaches Design
- Ein wenig Testen, ein wenig Programmieren ...
- Evolutionäres Design
- Natürlicher Abschluss einer Programmierepisode
- Refactoring
- Abschließende Reflexion
- Häufige Integration
- Rückblende
- "Aus dem Bauch" von Sabine Embacher
Kapitel 3: Unit Tests mit JUnit (PDF)
- Download und Installation
- Ein erstes Beispiel
- Anatomie eines Testfalls
- Test-First
- JUnit in Eclipse
- Das JUnit-Framework von innen
- »Assert«
- »AssertionFailedError«
- »TestCase«
- Lebenszyklus eines Testfalls
- »TestSuite«
- »TestRunner«
- Zwei Methoden, die das Testen vereinfachen
- Testen von Exceptions
- Unerwartete Exceptions
- "Woran erkennt man, dass etwas testgetrieben entwickelt wurde?" von Johannes Link
- JUnit 4
Kapitel 4: Testgetriebene Programmierung
- Die erste Direktive
- Der Testgetriebene Entwicklungszyklus
- Die Programmierzüge
- Beginn einer Testepisode
- Ein einfacher Testplan
- Erst ein neuer Test ...
- ... dann den Test fehlschlagen sehen
- ... schließlich den Test erfüllen
- Zusammenspiel von Test- und Programmcode
- Ausnahmebehandlung
- Ein unerwarteter Erfolg
- Ein unerwarteter Fehlschlag
- "Rückschritt für den Fortschritt" von Tammo Freese
- Vorprogrammierte Schwierigkeiten
- "Zwei offene Tests sind einer zu viel" von Tammo Freese
- Kleine Schritte gehen
- "Halten Sie Ihre Füße trocken" von Michael Feathers
Kapitel 5: Refactoring
- Die zweite Direktive
- Die Refactoringzüge
- Von übel riechendem Code ...
- ... über den Refactoringkatalog
- ... zur Einfachen Form
- Überlegungen zur Refactoringroute
- Substitution einer Implementierung
- Evolution einer Schnittstelle
- "Coding Standards bewusst verletzen" von Tammo Freese
- Teilen von Klassen
- Verschieben von Tests
- Abstraktion statt Duplikation
- Die letzte Durchsicht
- Ist Design tot?
- "Durch zerbrochene Fenster dringen Gerüche ein" von Dave Thomas & Andy Hunt
- Richtungswechsel ...
- ... und der wegweisende Test
- Fake it ('til you make it)
- Vom Bekannten zum Unbekannten
- Retrospektive
- Tour de Design évolutionnaire
- Durchbrüche erleben
Kapitel 6: Häufige Integration
- Die dritte Direktive
- Die Integrationszüge
- Änderungen mehrmals täglich zusammenführen ...
- "Taxi implements Throwable" von Olaf Kock
- ... das System von Grund auf neu bauen
- ... und ausliefern
- Versionsverwaltung (mit CVS oder Subversion)
- Build-Skript mit Ant
- Build-Prozess-Tuning
- Integrationsserver mit CruiseControl
- Aufbau einer Staging-Umgebung
- Teamübergreifende Integration
- Gesund bleiben
- "Eine Geschichte über die Häufige Integration" von Lasse Koskela
Kapitel 7: Testfälle schreiben, von A bis Z
- Aufbau von Testfällen
- Benennung von Testfällen
- Buchführung auf dem Notizblock
- Der erste Testfall
- Der nächste Testfall
- Erinnerungstests
- Ergebnisse im Test festschreiben, nicht berechnen
- Erst die Zusicherung schreiben
- Features testen, nicht Methoden
- Finden von Testfällen
- Generierung von Testdaten
- Implementierungsunabhängige Tests
- Kostspielige Setups
- Lange Assert-Ketten oder mehrere Testfälle?
- Lerntests
- Minimale Fixture!
- "Einfache Tests - einfaches Design" von Dierk König
- Negativtests
- Organisation von Testfällen
- Orthogonale Testfälle
- Parameterisierbare Testfälle
- Qualität der Testsuite
- Refactoring von Testcode
- Reihenfolgeunabhängigkeit der Tests
- Selbsterklärende Testfälle
- String-Parameter von Zusicherungen
- Szenarientests
- Testexemplare
- Testsprachen
- Umgang mit Defekten
- "Eine Frage der (Test-)Kultur" von Christian Junghans & Olaf Kock
- Umgang mit externem Code
- Was wird getestet? Was nicht?
- Zufälle und Zeitabhängigkeiten
- "Der zeitlose Weg des Testens" von Lasse Koskela
Kapitel 8: Isoliertes Testen, durch Stubs und Mocks
- Verflixte Abhängigkeiten!
- Was ist die Unit im Unit Test?
- Mikrointegrationstest versus strikter Unit Test
- Vertrauenswürdige Komponenten
- "Vertrauen - und Tests" von Bastiaan Harmsen
- Austauschbarkeit von Objekten
- Stub-Objekte
- Größere Unabhängigkeit
- Testen durch Indirektion
- Stub-Variationen
- Testen von Mittelsmännern
- Self-Shunt
- Testen von innen
- Möglichst frühzeitiger Fehlschlag
- Erwartungen entwickeln
- Gebrauchsfertige Erwartungsklassen
- Testen von Protokollen
- Mock-Objekte
- Wann verwende ich welches Testmuster?
- "Wo Mock-Objekte herkommen" von Tim Mackinnon & Ivan Moore & Steve Freeman
- Crashtest-Dummies
- Dynamische Mocks mit EasyMock
- Stubs via Record/Replay
- Überspezifizierte Tests
- Überstrapazierte Mocks
- Systemgrenzen im Test
- "Mock-Objekte machen glücklich" von Moritz Petersen
Kapitel 9: Entwicklung mit Mock-Objekten
- Tell, don't ask
- Von außen nach innen
- Wer verifiziert wen?
- Schnittstellen finden auf natürlichem Weg
- Komponierte Methoden
- Vom Mock lernen für die Implementierung
- Viele schmale Schnittstellen
- Kleine fokussierte Klassen
- Tell und Ask unterscheiden
- nereimmargorP sträwkcüR
- Schüchterner Code und das Gesetz von Demeter
- Fassaden und Mediatoren als Abstraktionsebene
- Rekonstruktion
- "Meister, ..." von Dierk König
Kapitel 10: Akzeptanztests mit FIT (Framework for Integrated Test)
- Von einer ausführbaren Spezifikation ...
- Download Now
- Schritt für Schritt für Schritt
- ... zum ausführbaren Anforderungsdokument
- Die drei Basis-Fixtures
- »ActionFixture«
- Richtung peilen, Fortschritt erzielen
- Fixture wachsen lassen, dann Struktur extrahieren
- Nichts als Fassade
- Die Fixture als zusätzlicher Klient
- Aktion: Neue Aktion
- »ColumnFixture«
- Fixture-Interkommunikation
- Negativbeispiele
- Transformation: Action -> Column
- »RowFixture«
- Einfacher Schlüssel
- Mehrfacher Schlüssel
- Abfragemethoden einspannen
- »Summary«
- "Warum drei Arten von Fixtures?" von Ward Cunningham
- »ExampleTests«
- »AllFiles«
- Setup- und Teardown-Fixtures
- Das FIT-Framework von innen
- »FileRunner«
- »Parse«
- »Fixture«
- Annotationsmöglichkeiten in Dokumenten
- »TypeAdapter«
- »ScientificDouble«
- Domänenspezifische Grammatiken
- »ArrayAdapter«
- »PrimitiveFixture«
- Domänenspezifische Fixtures
- Anschluss finden
- Stichproben reiner Geschäftslogik
- Integrationstests gegen Fassaden und Services
- "Survival of the FIT Test" von Steffen Künzel & Tammo Freese
- Oberflächentests
- Kundenfreundliche Namen
- FitNesse
- FitLibrary
- Akzeptanztesten aus Projektsicht
Kapitel 11: Änderbare Software
- "Harte Prozesse führen zu harten Produkten" von Dierk König
- Konstantes Entwicklungstempo
- "Alten Code testgetrieben weiterentwickeln" von Juan Altmayer Pizzorno & Robert Wenner
- "Die Latte liegt jetzt höher" von Michael Feathers
- Kurze Zykluszeiten
- Neue Geschäftsmodelle
- "Bug-Trap-Linien" von Michael Hill
Behandelte Werkzeuge
Quellcode
Die Beispiele aus den Kapiteln 2, 3, 4, 5, 6, 7, 8 können Sie sich auch hier herunterladen.