Tag Archives: bdd

Nachdem ich am Samstag voller Stolz meine FizzBuzz Speed Kata veröffentlich habe, möchte ich die daraus gewonnen Erkenntnisse natürlich mit euch teilen. Nach der Aufnahme des Videos fühlte ich mich gut und verzierte das Video noch mit ein paar Kommentaren. Schnell auf youtube veröffentlicht (das ganze war ja noch im 15 Minuten Limit) und ab nach nach Kaltbrunn – Hockey und so… Nachdem ich wieder zu Hause war, fielen mir und auch durch die Hilfe von Feedbacks doch einige Schwächen bei meiner Kata auf. Dies scheint aber gut zu sein, um etwas über TDD/BDD lernen zu können. Diese Methode hat nämlich nicht nur Vorteile.


 Read more...

Nachdem ich am Samstag voller Stolz meine FizzBuzz Speed Kata veröffentlich habe, möchte ich die daraus gewonnen Erkenntnisse natürlich mit euch teilen. Nach der Aufnahme des Videos fühlte ich mich gut und verzierte das Video noch mit ein paar Kommentaren. Schnell auf youtube veröffentlicht (das ganze war ja noch im 15 Minuten Limit) und ab nach nach Kaltbrunn - Hockey und so... Nachdem ich wieder zu Hause war, fielen mir und auch durch die Hilfe von Feedbacks doch einige Schwächen bei meiner Kata auf. Dies scheint aber gut zu sein, um etwas über TDD/BDD lernen zu können. Diese Methode hat nämlich nicht nur Vorteile. Vorteile/Chancen Es ist wirklich cool mit Behaviour Driven Development zu coden (bis jetzt habe ich ja nur TDD gemacht). Insgesamt fühle ich mich mit dem Syntax wohler und habe das Gefühl, die Anforderungen besser formulieren zu können. Ich habe BDD mit Specifications umgesetzt (es gibt ja auch die Variante mit Stories). Welche der 2 Notationen nun besser ist, kann ich momentan noch nicht sagen. BDD macht Spass. Alle Vorteile, die man mit TDD hat, hat man auch bei BDD - man hört ja auch immer wieder, dass BDD das verbesserte TDD ist. Code Katas sind definitiv lehrreich. Man kann mit den Übungen seine Fähigkeiten verbessern. Wenn man eine Kata gelöst hat, kann man sie nochmals lösen, einfach mit einem anderen Fokus (z.B. Speed, BDD üben, Code möglichst kurz, Code ohne IDE schreiben usw.) Gefahren/Stolpersteine Speed tut dem Hirn nicht gut - ich habe Fehler gemacht, die normalerweise nicht passieren. Diese habe ich im Video nachdokumentiert. Bei BDD/TDD verlässt man sich teilweise zu fest auf das rot/grün. Wenn es grün ist, ist alles gut!!! (Das es nicht so sein muss, sieht man ja im Video) BDD/TDD ersetzt nicht die Planungsphase. Es macht Sinn, zuerst die Architektur zu planen, bevor man mit coden beginnt (in einem so einfachen Beispiel wie FizzBuzz können z.B. einfach die "it" Blöcke, sprich die Requirements vorformuliert werden)