Jeans Store Hier klicken Neuerscheinungen Cloud Drive Photos Erste Wahl Learn More Hier klicken HI_PROJECT Fire Shop Kindle PrimeMusic Summer Sale 16

Kundenrezensionen

3,6 von 5 Sternen
11
3,6 von 5 Sternen
Format: Taschenbuch|Ändern
Preis:35,95 €+ Kostenfreie Lieferung mit Amazon Prime
Ihre Bewertung(Löschen)Ihre Bewertung


Derzeit tritt ein Problem beim Filtern der Rezensionen auf. Bitte versuchen Sie es später noch einmal.

am 10. Januar 2004
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.
0Kommentar| 17 Personen fanden diese Informationen hilfreich. War diese Rezension für Sie hilfreich?JaNeinMissbrauch melden
am 14. Juli 2014
Das Buch führt aus meiner Sicht sehr gut in das Thema Test-Driven Development ein.

Der Grundsatz: red, green, refactor ist praktikabel und ich nutze das Vorgehen seit einigen Wochen, und es macht Freunde.

Warum macht das Freude? Weil das Schreiben von Tests im Nachhinein einfach nur nervig ist.

Mich hat der Test-Virus befallen, und es lohnt sich. Die Qualität der Software steigt.

Bisher habe ich oft per strg-r (Browserreload) den Code getestet, und am Ende noch einen High-Level Test geschrieben.

Nun verwende ich viel mehr kleine Methoden, die sich mit kleinen Tests prüfen lassen.

Ich fand das Buch hilfreich. Teilweise habe ich auch einige Passagen übersprungen.
0Kommentar| Eine Person fand diese Informationen hilfreich. War diese Rezension für Sie hilfreich?JaNeinMissbrauch melden
am 18. November 2007
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.
0Kommentar| 49 Personen fanden diese Informationen hilfreich. War diese Rezension für Sie hilfreich?JaNeinMissbrauch melden
am 23. Mai 2003
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.
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.
11 Kommentar| 29 Personen fanden diese Informationen hilfreich. War diese Rezension für Sie hilfreich?JaNeinMissbrauch melden
am 12. März 2003
Im lockeren Stil beschreibt Kent Beck den TDD Softwareentwicklungsansatz: Zuerst den Test schreiben, dann folgt der Code und last but not least das Design. Mit einem ausführlichen Beispiel werden alle Aspekte von TDD erläutert und eingeführt. Zudem gibt es einen Bausatz für das eigene Testframework und dies erst noch ebenfalls in TDD Manier. Und zum Schluss diskutiert Kent Beck verschiedene Muster, die bei TDD immer wieder auftreten. Das Buch bietet für jeden etwas: Dem Einsteiger und auch dem Fortgeschrittenen. Ich arbeite schon längere Zeit mit TDD, doch konnte er auch mir noch einige neue Aspekte aufzeigen. Und das Buch las ich in kürzester Zeit, denn die lockere aber präzise Wissensvermittlung, kurzen prägnanten Kapitel und eingestreuten Lacher sind genau das, was ich auch von einem guten Fachbuch erwarte.
0Kommentar| 9 Personen fanden diese Informationen hilfreich. War diese Rezension für Sie hilfreich?JaNeinMissbrauch melden
am 1. April 2015
Ich kann mir nur den Meinung von Herrn Kaestner anschließen (siehe sein ausführlicher Bericht). Mein Englisch ist nicht das beste, aber wenn ein Fachbuch gut ist, dann konnte es mich noch immer fesseln. Hier jedoch fand ich nie einen roten Faden. Für mich was sowohl die Zeit als auch das Geld reine Verschwendung.
0Kommentar| Eine Person fand diese Informationen hilfreich. War diese Rezension für Sie hilfreich?JaNeinMissbrauch melden
am 3. Oktober 2006
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.

This book advocates 'code first - think later'.

The book builds on two examples in a fair amount of detail. In neither of them is there a clear definition of the problem. Neither of them has any statement relating to limits or accuracy (and anyone who has worked with currency conversions knows that how and when you do your rounding is critical).

Because he doesn't specify interfaces until he has finished his test - program cycle Kent Beck is advocating bottom-up rather than top-down development - how this succeeds in a project with more than a couple of developers is a mystery to me.

In any modern system the effort that goes into the user interface greatly exceeds the effort in the support routines but this book does not cover UI testing at all.

Given that the book is about 'testing to death', I found it especially irritating that Kent Beck's final example, which he added as an Appendix to show just how powerful TDD is, contains a glaring error.

The first example is in Java and the second in Python - I couldn't see any reason for changing the language in the middle of the book and, as he then goes back to Java again, it seems as if Kent Beck couldn't either.

On a purely personal level, the jokey style of the book annoyed me.

I award this book 2 stars rather than because the idea is interesting.

Finally, this is one of the few books where I have regretted my decision to buy it.
0Kommentar| 13 Personen fanden diese Informationen hilfreich. War diese Rezension für Sie hilfreich?JaNeinMissbrauch melden
am 25. Oktober 2003
Ein schönes, dünnes Buch das man schnell gelesen hat.
Kennt Beck treibt die kleinsten Test/Codier/Änderungs-Zyklen
bis zum Excess. Das scheint mir zu dogmatisch.
Aber das Buch regte mich angenehm dazu an meine eigenen Vorgehensweisen zu überdenken.
0Kommentar| 8 Personen fanden diese Informationen hilfreich. War diese Rezension für Sie hilfreich?JaNeinMissbrauch melden
am 28. April 2010
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.

Es ist schnell gelesen und bietet - meiner Meinung nach - ausser fuer Neulinge, nicht wirklich was Neues.

Trotzdem, sehr zu empfehlen (wenn auch vielleicht nur als Auffrischung zum Thema 'TDD').
0Kommentar|War diese Rezension für Sie hilfreich?JaNeinMissbrauch melden
am 30. November 2002
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 Ansatz wirklich verstehen und auch test getrieben programmieren.
Kent Beck schreibt wieder in seinem bekannten und genailen Stil, so dass man wirklich den Kern der Materie verstehen kann. Das Buch ist nicht nur für XP Entwickler interessant sondern auch für jeden anderen der robusten Code schreiben möchte.
0Kommentar| 6 Personen fanden diese Informationen hilfreich. War diese Rezension für Sie hilfreich?JaNeinMissbrauch melden