|
||||||||||||||||||||
|
||||||||||||||||||||
|
||||||||||||||||||||
| ||||||||||||||||||
 Gutschein erhalten
Tauschen Sie jetzt Test Driven Development. By Example (Addison-Wesley Signature) gegen einen Amazon-Gutschein in Höhe von EUR 10,30 ein - einlösbar für Tausende von Artikeln bei Amazon.de. Entdecken Sie mehr eintauschbare Bücher im Bücher Trade-In Shop. Bitte beachten Sie die Teilnahmebedingungen.
 Jetzt für Amazon Student anmelden und um 20% erhöhten Eintauschwert sichern. |
Wird oft zusammen gekauft
Produktinformation
Möchten Sie die Produktinformationen aktualisieren oder Feedback zu den Produktabbildungen geben?
Ist der Verkauf dieses Produkts für Sie nicht akzeptabel? |
Mehr über den Autor
Entdecken Sie Bücher, lesen Sie über Autoren und mehr
› Besuchen Sie die Seite von Kent Beck auf Amazon
› Besuchen Sie die Seite von Kent Beck auf Amazon
Produktbeschreibungen
Kurzbeschreibung
Quite simply, test-driven development is meant to eliminate fear in application development. While some fear is healthy (often viewed as a conscience that tells programmers to "be careful!"), the author believes that byproducts of fear include tentative, grumpy, and uncommunicative programmers who are unable to absorb constructive criticism. When programming teams buy into TDD, they immediately see positive results. They eliminate the fear involved in their jobs, and are better equipped to tackle the difficult challenges that face them. TDD eliminates tentative traits, it teaches programmers to communicate, and it encourages team members to seek out criticism However, even the author admits that grumpiness must be worked out individually! In short, the premise behind TDD is that code should be continually tested and refactored. Kent Beck teaches programmers by example, so they can painlessly and dramatically increase the quality of their work.
Synopsis
Quite simply, test-driven development is meant to eliminate fear in application development. While some fear is healthy (often viewed as a conscience that tells programmers to "be careful!"), the author believes that byproducts of fear include tentative, grumpy, and uncommunicative programmers who are unable to absorb constructive criticism. When programming teams buy into TDD, they immediately see positive results. They eliminate the fear involved in their jobs, and are better equipped to tackle the difficult challenges that face them. TDD eliminates tentative traits, it teaches programmers to communicate, and it encourages team members to seek out criticism However, even the author admits that grumpiness must be worked out individually! In short, the premise behind TDD is that code should be continually tested and refactored. Kent Beck teaches programmers by example, so they can painlessly and dramatically increase the quality of their work.
Welche anderen Artikel kaufen Kunden, nachdem sie diesen Artikel angesehen haben?
Tags, die Kunden mit diesem Produkt verbinden(Was ist das?)Klicken Sie zum Suchen verwandter Artikel, Diskussionen oder Personen auf ein Tag.
|
Eine digitale Version dieses Buchs im Kindle-Shop verkaufen
Wenn Sie ein Verleger oder Autor sind und die digitalen Rechte an einem Buch haben, können Sie die digitale Version des Buchs in unserem Kindle-Shop verkaufen.
Weitere Informationen
Kundenrezensionen
Die hilfreichsten Kundenrezensionen
34 von 38 Kunden fanden die folgende Rezension hilfreich
Format:Taschenbuch
Das Buch sollte die praktische Anwendung von testgetriebener Entwicklung an Beispielen zeigen. Ich hatte das Buch gekauft in der Hoffnung mich damit ueberzeugen zu lassen, leider hat dies nicht geklappt.
Das Buch beginnt mit einem ausfuehrlichen, aber nahezu trivialen Beispiel, dem Umrechnen von Waehrungen. Daran erklaert es zwar anschaulich den Ansatz, Problem ist aber dass das Problem so einfach ist dass man den ganzen Ueberbau kaum braucht. Die gesamte Endloesung ist so klein dass sie problemlos auf eine Bildschirmseite passt, was bleibt ist lediglich die Beschreibung des Prozesses.
In einem zweiten Abschnitt nimmt er sich ein etwas komplexeres Beispiel in einer anderen Programmiersprache. Dummerweise ist das Beispiel IMHO sehr schlecht gewaehlt, es geht ums bootstrapping von einer xUnit Implementierung, was die Beschreibung unnoetig kompliziert macht (z.B. TestCaseTest als Test fuer eine TestCase klasse mit der man Tests beschreiben kann). Insgesamt ist aber auch dieses Beispiel wieder sehr einfach und kann insgesamt nicht ueberzeugen.
Der dritte und letzte Abschnitt widmet sich der Diskussion und ist wahrscheinlich noch der Beste, waeren da nicht zwei voellig unmotivierte Kapitel zu Design Pattern und Refactoring. Diese Kapitel sind zu kurz fuer Leute die diese Konzepte noch nicht kennen und voellig unnuetz fuer Leute die diese Konzepte kennen. Ein Zusammenhang zur testgetriebenen Entwicklung wird nicht wirklich hergestellt.
Nach dem Lesen des Buches bleiben mehr offene Fragen als vorher. Es gibt keine Anhaltspunkte wie man den Ansatz skaliert wenn man etwas kompliziertes entwickelt als mathematische Algorithmen. Spannende Fragen zu komplexen Strukturen, Datenbankanbindungen, Oberflaechen, Nutzerinteraktion o.ae. werden in den letzten Kapitel kurz erwaehnt aber weitgehend offen gelassen. Das Buch liefert leider wirklich nicht mehr als zwei einfache(!) Beispiele.
Das Buch ist ziemlich duenn und sehr lachs geschrieben, mit staendigen Metakommentaren. Geschackssache. Leider staendig Behauptungen ohne jedwede Belege (wie auch praktisch keinerlei weiterfuehrende Literatur angegeben ist). Ganz selten wird mal eine Fallstudie erwaehnt. Es wirkt alles wie eine fixe Idee ohne Substanz, obwohl ich eigentlich testgetriebende Entwicklung gar nicht so eingeschaetzt haette. Buecher wie Code Complete sind hier um Welten besser geschrieben.
Fazit: Nicht empfehlenswert.
Das Buch beginnt mit einem ausfuehrlichen, aber nahezu trivialen Beispiel, dem Umrechnen von Waehrungen. Daran erklaert es zwar anschaulich den Ansatz, Problem ist aber dass das Problem so einfach ist dass man den ganzen Ueberbau kaum braucht. Die gesamte Endloesung ist so klein dass sie problemlos auf eine Bildschirmseite passt, was bleibt ist lediglich die Beschreibung des Prozesses.
In einem zweiten Abschnitt nimmt er sich ein etwas komplexeres Beispiel in einer anderen Programmiersprache. Dummerweise ist das Beispiel IMHO sehr schlecht gewaehlt, es geht ums bootstrapping von einer xUnit Implementierung, was die Beschreibung unnoetig kompliziert macht (z.B. TestCaseTest als Test fuer eine TestCase klasse mit der man Tests beschreiben kann). Insgesamt ist aber auch dieses Beispiel wieder sehr einfach und kann insgesamt nicht ueberzeugen.
Der dritte und letzte Abschnitt widmet sich der Diskussion und ist wahrscheinlich noch der Beste, waeren da nicht zwei voellig unmotivierte Kapitel zu Design Pattern und Refactoring. Diese Kapitel sind zu kurz fuer Leute die diese Konzepte noch nicht kennen und voellig unnuetz fuer Leute die diese Konzepte kennen. Ein Zusammenhang zur testgetriebenen Entwicklung wird nicht wirklich hergestellt.
Nach dem Lesen des Buches bleiben mehr offene Fragen als vorher. Es gibt keine Anhaltspunkte wie man den Ansatz skaliert wenn man etwas kompliziertes entwickelt als mathematische Algorithmen. Spannende Fragen zu komplexen Strukturen, Datenbankanbindungen, Oberflaechen, Nutzerinteraktion o.ae. werden in den letzten Kapitel kurz erwaehnt aber weitgehend offen gelassen. Das Buch liefert leider wirklich nicht mehr als zwei einfache(!) Beispiele.
Das Buch ist ziemlich duenn und sehr lachs geschrieben, mit staendigen Metakommentaren. Geschackssache. Leider staendig Behauptungen ohne jedwede Belege (wie auch praktisch keinerlei weiterfuehrende Literatur angegeben ist). Ganz selten wird mal eine Fallstudie erwaehnt. Es wirkt alles wie eine fixe Idee ohne Substanz, obwohl ich eigentlich testgetriebende Entwicklung gar nicht so eingeschaetzt haette. Buecher wie Code Complete sind hier um Welten besser geschrieben.
Fazit: Nicht empfehlenswert.
16 von 18 Kunden fanden die folgende Rezension hilfreich
Format:Taschenbuch
In seinem Buch "Test-Driven Development" (TDD) beschreibt Kent Beck den "Test-First"-Ansatz anhand von zwei großen Real-World-Beispielen: einer Währungs-Klasse in Java und einem xUnit-Test-Framework in Python.
Dabei führt Kent Beck den Leser in unterhaltsamer, gut verständlicher Sprache durch die Beispiele. Er geht dabei in sehr kleinen, leicht nachzuvollziehenden Schritten vor, anhand derer der Geist des Test-First-Programming sehr deutlich wird. Zeitweilig wirkt diese Vorgehensweise aber auch etwas langatmig, und einige wenige Design-Entscheidungen wirken sehr willkürlich und an den Haaren herbeigezogen.
Die Beispiele sind bei brauchbaren Vorkenntnissen in der jeweiligen Sprache (Java bzw. Python) gut zu verstehen. Wer die Sprachen jedoch bisher noch nicht benutzt hat, muss sich auf etwas anstrengendere Lektüre gefasst machen - so der von Beck angepriesene "Nebenher-Python-Lernen-Effekt" ist bei mir jedenfalls nicht aufgetreten.
Abgerundet wird das Buch durch ein großes Kapitel, welche Patterns TDD benutzt werden: Entwicklungsstrategien, Teststrategien, Design Patterns, Refactoring und andere. Dieses Kapitel ist das Glanzstück dieses Buches.
Generell lässt das Buch den "Test-Infected"-Virus überspringen und vermittelt die beim TDD angewandten Strategien sehr anschaulich. Es bietet sich daher als ergänzende Lektüre zusätzlich zu einer Einführung in TDD wunderbar an.
27 von 33 Kunden fanden die folgende Rezension hilfreich
Format:Taschenbuch
Test-getriebene Entwicklung hat sich aus den vorausgehenden Tests von Extreme Programming entwickelt, setzt aber prinzipiell keine agile Vorgehensweise im Projekt voraus. Dadurch ist sie auch einsetzbar, wenn das Projekt prinzipiell konventionell durchgeführt wird, zielt aber prinzipiell nur auf die Unit-Tests ab.
Bei Test-getriebener Entwicklung wird - wie der Name schon sagt - die Entwicklung durch automatisierte Tests getrieben, indem neuer Code nur dann geschrieben wird, wenn ein automatisierter Test fehlgeschlagen hat. Außerdem wird darauf geachtet, dass duplizierter Code durch Refactoring eliminiert wird. Diese beiden einfachen Regeln erzeugen ein komplexes Verhalten von Individuen und Gruppen:
*) Die Entwickler müssen Tests schreiben, bevor sie die Implementierung schreiben. Dadurch wächst der Entwurf (und somit die Anwendung) organisch.
*) Die Entwickler müssen die Tests selbst schreiben, weil sie nicht ständig darauf warten können, dass das die Tester machen.
*) Die Entwicklungsumgebung muss rasche Antworten liefern, damit Änderungen schnell durchgeführt werden können.
*) Der Entwurf muss aus vielen hoch-kohäsiven und lose gekoppelten Komponenten bestehen, weil er dadurch leicht testbar wird.
Der Entwickler geht bei Test-getriebener Entwicklung in den folgenden drei einfachen Schritten vor:
*) Rot: Schreibe einen kleinen Test, der noch nicht funktionieren kann (und sich eventuell auch noch gar nicht übersetzen lässt).
*) Grün: Mache, dass der Test so schnell wie möglich gut geht (auch wenn du dazu Sünden begehen musst).
*) Refactoring: Eliminiere duplizierten Code, der im zweiten Schritt eingeführt wurde.
Diese Vorgehensweise hat den psychologischen Effekt, dass sich der Entwickler auf kleine Schritte fokussieren kann und das Ziel (sauberer Code, der funktioniert) nicht aus den Augen verliert. Wenn bisher durch erhöhten Stress weniger Zeit zum Testen geblieben ist, dadurch wiederum weniger getestet wurde, hat das sehr leicht zu einem Teufelskreis geführt, mit immer mehr Unsicherheit und Stress. Test-getriebene Entwicklung hingegen führt dazu, dass der Entwickler bei erhöhtem Stress einfach öfters die bereits vorliegenden automatisierten Tests durchführt. Dadurch bekommt er unmittelbar die Rückmeldung, dass ohnehin noch alles funktioniert, was den Stress reduziert und die Fehlerwahrscheinlichkeit sinken lässt.
Die ersten beiden Schritte sind mit den Farben »rot« und »grün« eingeleitet, weil die Tests typischerweise mit Hilfe eines Test-Frameworks geschrieben werden bei dem Fehler rot angezeigt werden.
Test-getriebene Entwicklung bezieht sich allerdings nur auf die Tests, die der Entwickler selbst durchführt, d.h. auf die Unit-Tests, deren Umfang eventuell weiter gesehen wird als bei rein konventioneller Vorgehensweise. Funktionale Tests durch eigene Tester bzw. Systemtests werden nicht eigens adressiert aber auch nicht ausgeschlossen.
Bei Test-getriebener Entwicklung wird - wie der Name schon sagt - die Entwicklung durch automatisierte Tests getrieben, indem neuer Code nur dann geschrieben wird, wenn ein automatisierter Test fehlgeschlagen hat. Außerdem wird darauf geachtet, dass duplizierter Code durch Refactoring eliminiert wird. Diese beiden einfachen Regeln erzeugen ein komplexes Verhalten von Individuen und Gruppen:
*) Die Entwickler müssen Tests schreiben, bevor sie die Implementierung schreiben. Dadurch wächst der Entwurf (und somit die Anwendung) organisch.
*) Die Entwickler müssen die Tests selbst schreiben, weil sie nicht ständig darauf warten können, dass das die Tester machen.
*) Die Entwicklungsumgebung muss rasche Antworten liefern, damit Änderungen schnell durchgeführt werden können.
*) Der Entwurf muss aus vielen hoch-kohäsiven und lose gekoppelten Komponenten bestehen, weil er dadurch leicht testbar wird.
Der Entwickler geht bei Test-getriebener Entwicklung in den folgenden drei einfachen Schritten vor:
*) Rot: Schreibe einen kleinen Test, der noch nicht funktionieren kann (und sich eventuell auch noch gar nicht übersetzen lässt).
*) Grün: Mache, dass der Test so schnell wie möglich gut geht (auch wenn du dazu Sünden begehen musst).
*) Refactoring: Eliminiere duplizierten Code, der im zweiten Schritt eingeführt wurde.
Diese Vorgehensweise hat den psychologischen Effekt, dass sich der Entwickler auf kleine Schritte fokussieren kann und das Ziel (sauberer Code, der funktioniert) nicht aus den Augen verliert. Wenn bisher durch erhöhten Stress weniger Zeit zum Testen geblieben ist, dadurch wiederum weniger getestet wurde, hat das sehr leicht zu einem Teufelskreis geführt, mit immer mehr Unsicherheit und Stress. Test-getriebene Entwicklung hingegen führt dazu, dass der Entwickler bei erhöhtem Stress einfach öfters die bereits vorliegenden automatisierten Tests durchführt. Dadurch bekommt er unmittelbar die Rückmeldung, dass ohnehin noch alles funktioniert, was den Stress reduziert und die Fehlerwahrscheinlichkeit sinken lässt.
Die ersten beiden Schritte sind mit den Farben »rot« und »grün« eingeleitet, weil die Tests typischerweise mit Hilfe eines Test-Frameworks geschrieben werden bei dem Fehler rot angezeigt werden.
Test-getriebene Entwicklung bezieht sich allerdings nur auf die Tests, die der Entwickler selbst durchführt, d.h. auf die Unit-Tests, deren Umfang eventuell weiter gesehen wird als bei rein konventioneller Vorgehensweise. Funktionale Tests durch eigene Tester bzw. Systemtests werden nicht eigens adressiert aber auch nicht ausgeschlossen.
Kent Beck zeigt dem Leser anhand eines langen Beispiels, wie er arbeitet, und gibt anschließend Patterns zum Schreiben von Tests, Code und Testframeworks.
Ein weiterer Vorteil des Buchs ist, dass man es an einem Tag lesen kann.
Möchten Sie weitere Rezensionen zu diesem Artikel anzeigen?
Waren diese Rezensionen hilfreich?
Wir wollen von Ihnen hören.
Die neuesten Kundenrezensionen
Als Einfuehrung in TDD ganz ok
Das Buch vermittelt eine sehr gute Einfuehrung in die Welt von Test-Driven Development (TDD).
Die Beschreibungen sowie die Code-Beispiele sind ausfuehrlich und klar. Lesen Sie weiter...
Die Beschreibungen sowie die Code-Beispiele sind ausfuehrlich und klar. Lesen Sie weiter...
Veröffentlicht am 28. April 2010 von robert oh.
Disappointingly lacking in substance
As a developer I try to achieve a balance between producing a paper design that goes down to the level of code, and coding without having thought about the problem. Lesen Sie weiter...
Veröffentlicht am 3. Oktober 2006 von Malcolm Howlett
Klare Linie, lockerer Schreibstil
Kent Beck schafft es mit diesem Buch, das Thema Test Driven Development locker zu vermitteln. Die entsprechenden Beispiele unterstreichen das. Lesen Sie weiter...
Veröffentlicht am 26. Mai 2005 von Marco Jacob
Anregende Ideen
Ein schönes, dünnes Buch das man schnell gelesen hat.
Kennt Beck treibt die kleinsten Test/Codier/Änderungs-Zyklen
bis zum Excess. Lesen Sie weiter...
Kennt Beck treibt die kleinsten Test/Codier/Änderungs-Zyklen
bis zum Excess. Lesen Sie weiter...
Veröffentlicht am 25. Oktober 2003 von Marcel Ruff
Ansporn zum Ausprobieren
Im lockeren Stil beschreibt Kent Beck den TDD Softwareentwicklungsansatz: Zuerst den Test schreiben, dann folgt der Code und last but not least das Design. Lesen Sie weiter...
Veröffentlicht am 12. März 2003 von Daniel Flück
Sehr interessant!
Die TDD ist wirklich sehr interessant. Ich habe mich schon seit längerer Zeit dafür interessiert, seitdem ich mich über XP informiert habe, aber jetzt kann ich den... Lesen Sie weiter...
Veröffentlicht am 30. November 2002 von roy_schneider
Kunden diskutieren
|
Das Forum zu diesem Produkt
Fragen stellen, Meinungen austauschen, Einblicke gewinnen Aktive Diskussionen in ähnlichen Foren
Kundendiskussionen durchsuchen
|
Ähnliche Foren
|
||||||||||||||||||||||||||||||||||
Lieblingslisten
|
|
Ähnliche Artikel finden
Anhand des Sachgebietes nach ähnlichen Produkten suchen:
Ihr Kommentar
Möchten Sie die Produktinformationen aktualisieren oder Feedback zu den Produktabbildungen geben?
|
