Posts tagged ‘Testing’

Red Pencil Code Kata

At one of my clients I have seen a real feature request being used as a Code Kata. I found the feature description very interesting and created a Code Kata description from it:

Red Pencil Code Kata

We provide a shopping portal, where dealers can offer their goods (similiar to Amazon market place). We want to support red pencil promotions for reduced prices. During the red pencil promotion the old price is crossed out in red and the new reduced price is written next to it.
To avoid misuse of red pencil promotions the red pencil promotions are activated and deactivated automatically.
The scope of the Code Kata is the implementations of the rules for activation and end of red pencil promotions.
  • A red pencil promotion starts due to a price reduction. The price has to be reduced by at least 5% but at most bei 30% and the previous price had to be stable for at least 30 days.
  • A red pencil promotion lasts 30 days as the maximum length.
  • If the price is further reduced during the red pencil promotion the promotion will not be prolonged by that reduction.
  • If the price is increased during the red pencil promotion the promotion will be ended immediately.
  • If the price if reduced during the red pencil promotion so that the overall reduction is more than 30% with regard to the original price, the promotion is ended immediately.
  • After a red pencil promotion is ended additional red pencil promotions may follow – as long as the start condition is valid: the price was stable for 30 days and these 30 days don’t intersect with a previous red pencil promotion.

March 4, 2011 at 3:54 pm 7 comments

Poll about code katas

We have created a poll about code katas to better understand the current use of code katas and the needs of programmers doing code katas. Please help us to gather the data and participate in the anonymuous poll (only eats 5 minutes of your time): Participate in Poll and please spread the link to the poll.

We will puplish the results after the poll ended.

October 7, 2010 at 2:02 pm Leave a comment

Code Katas with CodersDojo.com

Code Katas become more and more popular: little programming tasks, that programmers solve several times – every time a little better.

CodersDojo.org supports performing and improving Code Katas. Opening http://codersdojo.org with the internet browser of your choice shows the home page of CodersDojo.

By clicking “Enter the Dojo” we enter the virtual Dojo, where we perform the Kata (until now only Ruby is supported).

In the right area a dummy test is displayed. We replace the dummy test with the first (test) step of our Kata (in this case the Fibonacci numbers). To make things simple we put production and test code in the same file.

With clicking “Run” we run the test. The result is displayed in the left screen area.

Now we write only so much production code that the test succeeds.

This way we test drive the solution.

By clicking “Finish” we get the analysis of the Kata.

There we see the overall duration of the Kata, the number of steps and a visualization of the TDD steps (red, green).

To improve the Kata we can give a collegue access to the Kata so that he can give feedback. We simply send him the link that is displayed at the bottom of the page. When the collegue opens the link he starts with the first step of the Kata. On the left side he can see the Code before and after the first “Run”. On the right side a text area waits for comments.

Our collegue can navigate forth and back through the Kata. When something strikes our collegue he adds his comment to the step.

Try it and give us feedback about CodersDojo!

June 23, 2010 at 6:46 pm Leave a comment

Code-Katas in CodersDojo.com

Code-Katas erfreuen sich zunehmender Beliebtheit: kleine Programmieraufgaben, die man mehrfach löst und jede Lösung ein wenig verbessert.

CodersDojo.org unterstützt Code-Katas. Nach Aufruf von http://codersdojo.org erscheint die Start-Seite.

Mit “Enter the Dojo” betreten wir das virtuelle Dojo, in dem wir die Kata durchführen (bisher nur in Ruby).

Im rechten Bereich wird ein Dummy-Test vorgeschlagen. Wir ersetzen den Dummy-Test durch den ersten (Test-)Schritt unserer Kata (in diesem Fall die Fibonacci-Reihe). Um die Angelegenheit möglichst einfach zu gestalten, schreiben wir Produktiv- und Testcode in dieselbe Datei.

Durch click auf “Run” führen wir unseren Test aus. Links wird das Ergebnis der Testausführung angezeigt.

Jetzt schreiben wir soviel Produktivcode, dass der Test durchläuft.

So entwickeln wir schrittweise testgetrieben unsere Lösung.

Durch click auf “Finish” gelangen wir zur Auswertung der Kata.

Dort sehen wir die Gesamtdauer der Kata, die Anzahl der Schritte und eine Visualisierung der TDD-Schritte (rot, grün).

Zur Verbesserung der eigenen Fähigkeiten können wir die Kata einem Kollegen zur Kommentierung zur Verfügung stellen. Dazu senden wir ihm den Link, der unten auf der Seite angegeben ist. Öffnet der Kollege den Link, sieht er den ersten Schritt der Kata. Links sieht er den Code vor und nach dem ersten “Run”. Rechts steht ein Feld für seine Kommentare zur Verfügung.

Der Kollege kann durch die Kata navigieren. Wo ihm etwas auffällt, schreibt er seinen Kommentar zu dem Schritt dazu.

Probiert es einfach mal aus und gebt uns Feedback zu CodersDojo.

June 2, 2010 at 7:29 pm Leave a comment

Code Kata Bunkai: Prime Factors

Bernd Schiffer has published a screencast of the Prime Factors Code Kata that we prepared.
When a programmer new to TDD watches such a code kata he has the same problem that an unexperiences karate student has when he watches a karate kata. He can see what’s happening but he has no idea why.
In karate there is a second kata flavour: Bunkai:

Bunkai literally meaning “analysis” or “disassembly”, is a term used in Japanese martial arts referring to the application of fighting techniques extracted from the moves of a “form” (kata) (see Wikipedia).

When watching a kata bunkai it becomes pretty obvious why the moves of the kata are done.
The same should be possible with code katas. Therefore we tried to transfer the bunkai concept to code katas. For now that simply means that the non obvious parts of the code kata are explained. I published the result for the prime factors code kata on YouTube.

I have to confess that I simply cut Bernds video. I think the real code kata bunkai should include the explanation in the kata – like it is in karate. We will work on that.

January 7, 2010 at 7:46 am 13 comments

Vortrag zum inkrementellen Entwurf auf XP-Days und Scrum-Gathering

Die Präsentation zum inkrementellen Entwurf, die ich auf den XP-Days Germany in Karlsruhe gehalte habe, findet sich hier als Prezi-Flash-Präsentation.

Einen fast identischen Vortrag habe ich auch auf dem Scrum-Gathering in München gehalten. Hier ist die Prezi-Präsentation dazu.

Die Präsentationen habe ich mit Prezi erstellt. Die Vorteile von Prezi aus meiner Sicht, habe ich bereits in einem anderen Blogeintrag beschrieben.

December 2, 2009 at 11:54 am Leave a comment

Mikroschritte in Code-Kata

Bernd Schiffer und ich haben eine Code-Kata mit TDD programmiert. Nach ein paar Refactorings hatten wir Groovy-Code, der ungefähr so aussah (ich habe das konkrete Beispiel gegen ein einfacheres ausgetauscht):

def toString(number, range = (1..number).reverse()) {
    if (range.empty) return ""
    def item = range.last()
    "$item" + toString(number, range - item)
}

assert '1' == toString(1)
assert '12' == toString(2)
assert '123' == toString(3)
assert '1234567891011' == toString(11)

"toString" liefert einen String mit den Zahlen 1 bis "number". In "range" finden sich die jeweils noch zu bearbeitenden Zahlen. Das kann man in Groovy natürlich viel einfacher hinschreiben:

def toString(number) {
	(1..number).join() 
}


Aber für den Punkt dieses Blog-Beitrags bleiben wir bei der ursprünglichen Implementation. Wir bleiben also bei der "range" und fokussieren auf ein anderes Problem. Wir verdrehen bei der Erzeugung der Range die Reihenfolge mit "reverse" und greifen hinterher mit "last" darauf zu. Es wäre einfacher, wenn wir die Reihenfolge unverändert ließen und mit "first" auf das jeweils erste Element zugreifen würden. Wir brauchen also ein Refactoring, das diese beiden Stellen im Code ändert.

Dummerweise steht der Bernd davor. Er ist dagegen, dass wir einfach diese zwei Stellen im Code ändern. Er meint, das sei nicht der "grüne Weg", weil nach der ersten Änderung (entfernen von "reverse") die Tests (asserts) nicht mehr laufen. "Aber alle zwei Änderungen finden in derselben Methode statt. Das kann man doch problemlos in einem Schritt ändern und dann ist alles grün. So ist es doch viel schneller." Aber Bernd bleibt dabei. Das ist ihm zu großschrittig (ein Schulungsteilnehmer sagte einmal sinngemäß "Ich dachte immer kleiner als Elektron geht nicht, aber jetzt kenne ich den Bernd-Schritt als kleinstes Element."):

  1. Wir arbeiten an einer Code-Kata. Dabei geht es darum, dass wir unsere Programmierfähigkeiten verbessern. Es geht nicht darum, die Kata in möglichst kurzer Zeit durchzuführen. Es geht darum, sie möglichst gut durchzuführen - wie bei einer Karate-Kata.
  2. Wir stehen in der Praxis immer wieder vor großen Refactorings, die wir nicht in kleine Schritte zerlegt bekommen und die uns den letzten Nerv kosten. Je kleinschrittiger wir vorgehen können, umso besser können wir große Refactorings zerlegen. Wenn wir es schaffen, dass die Tests nach jeder Änderung eines Ausdrucks grün sind, dann können wir für jedes große Refactoring einen komplett grünen und damit sicheren Weg beschreiten.
  3. Wenn wir mehrere Änderungen auf einmal durchführen, laufen wir immer Gefahr, versehentlich Funktionalität zu erweitern - die dann nicht durch Tests abgedeckt ist. Wenn wir jeweils nur einen Ausdruck ändern, können wir normalerweise sehr sicher abschätzen, ob wir die Funktionalität erweitert haben.

"OK, Bernd hat Recht. Versuchen wir es Kleinstschrittig. Äh, geht das denn überhaupt?"

Ja, es geht. Gleicht kommt die Lösung. Wer sich selbst an der Aufgabe versuchen möchte, sollte hier nicht weiterlesen und es erstmal selbst versuchen. Die Regel: Einen Ausdruck ändern, Tests ausführen, es muss alles grün sein. Danach der nächste Ausdruck.

Eine Lösung
Es gibt verschiedene Möglichkeiten, das Problem zu lösen. Hier eine mögliche Lösung:

Zuerst vereinfache ich den "range"-Defaultwert, indem ich das umdrehen der Elemente bereits beim Hinschreiben erledige:

def toString(number, range = number..1) {
    if (range.empty) return ""
    def item = range.last()
    "$item" + toString(number, range - item)
}


Jetzt kommt der interessante Teil. Die Reihenfolge der Elemente in "range" hängt direkt mit dem Zugriff über "last" zusammen. Wenn ich "last" durch "first" ersetzen möchte, muss ich dafür sorgen, dass in "range" am Anfang und Ende dasselbe Element steht. Das erreiche ich, indem ich "range" quasi verdoppele:

def toString(number, range = (1..number)+(number..1)) {
    if (range.empty) return ""
    def item = range.last()
    "$item" + toString(number, range - item)
}


Dass "range" jetzt jede Zahl doppelt enthält, schadet nicht, weil "range - item" alle "item"s entfernt. Mit diesem verdoppelten Range liefert "last" dasselbe Ergebnis wie "first", so dass ich die Ersetzung problemlos vornehmen kann.

def toString(number, range = (1..number)+(number..1)) {
    if (range.empty) return ""
    def item = range.first()
    "$item" + toString(number, range - item)
}


Jetzt kann ich den Default-Wert für "range" wieder vereinfachen:

def toString(number, range = 1..number) {
    if (range.empty) return ""
    def item = range.first()
    "$item" + toString(number, range - item)
}


Und fertig bin ich mit meinem Refactoring. Wir haben nach jeder Änderung eines Ausdrucks die Tests durchlaufen lassen und sie waren immer grün. In der Praxis würde man in diesem Beispiel vielleicht nicht so kleinschrittig vorgehen. Aber hier geht es um den Trainingseffekt!

Eine interessante Frage ist sicherlich, ob es immer solche kleinschrittigen Auflösungen gibt oder ob es Fälle gibt, wo das nicht funktioniert. Wenn Ihr Refactoring-Beispiele habt, von denen Ihr glaubt, dass es keine Kleinstschrittige Zerlegung gibt, schickt mir die! Entweder an stefan AT stefanroock DOT de (AT durch @ und DOT durch . ersetzen) oder als Kommentar an diesen Blog-Beitrag.

December 1, 2009 at 6:22 pm 10 comments

Programmierkatas

Auf den XP-Days Germany 2009 fand ein Format namens “TDD mit den Profis” statt. Die Idee ist, dass Paare bestehend aus einem TDD-Profi und einem nicht so erfahrenen TDDler gegeneinander antreten. Die Paare führen in kurzer Zeit TDD und Pair-Programming vor. Bei den XP-Days hatten die Paare in der Vorrunde 5 Minuten Zeit und im Finale 8 Minuten.
Ich bin mit meiner Pair-Partnerin ins Finale gekommen, musste mich dort aber mit dem zweiten Platz zufrieden geben.

In der Vorrunde konnten sich die Paare sehr frei aussuchen, was sie vorführen. Im Finale gab es vorgegebene Code-Katas (siehe Konzept der Code-Katas siehe Wikipedia). Für die Vorrunde hatten wir mehrere Tage für die Vorbereitung Zeit, für das Finale 2 Stunden.

Code-Katas hatte ich vorher bereits programmiert. Allerdings nicht so, wie es für die XP-Days-Sessions notwendig war. In der Kürze der Zeit lässt sich nur dann sinnvoll etwas zeigen, wenn man die Übung auswendig und flüssig vorführen kann. Und dafür muss man sie einüben. Und das bedeutet, die Kata in der Vorbereitung mehrfach zu programmieren und immer wieder zu variieren, um den besten Ablauf zu finden.

Und dieses mehrfache Programmieren derselben Aufgabe war entgegen meinen Erwartungen nicht langweilig, sondern sehr interessant und lehrreich. So haben wir auf der Konferenz meine Finalaufgabe (Primfaktorzerlegung) nochmal während des Community-Day programmiert (im Rahmen eines Coding Dojos) und auf der Rückfahrt von Karlsruhe mit der Bahn nach Hamburg haben Bernd Schiffer und ich die Code-Kata nochmal programmiert.

Robert Martin hat die Code-Kata sogar zu Musik vorgeführt und damit Programmierung in die Nähe einer Kunstform gebracht.

November 29, 2009 at 9:36 pm 2 comments

Lernen im dritten Quartal 2009

Damit habe ich mich im dritten Quartal 2009 beschäftigt:

  • Ich habe das Buch Subject to Change gelesen. Meine Eindrücke habe ich bereits im Blog beschrieben: Es geht darum, wie heute Produkte und Services entwickelt werden müssen. Das ganze passt wenig überraschend mit agilen Ansätzen wie Scrum ganz wunderbar zusammen.
  • Dann habe ich mich ziemlich intensiv mit Prolog beschäftigt und einige Beiträge in diesem Blog darüber veröffentlicht. Das war allemal horizonterweiternd – Prolog ist eben doch sehr anders als andere Programmiersprachen. Ich finde es nach wie vor Schade, dass Prolog heute ziemlich tot zu sein scheint und die Sprache nicht ernsthaft weiterentwickelt wird. Relektionen über Prolog.
  • In Prolog habe ich ann auch gleich ein kleines BDD-Framework gebaut und damit mein BDD-Verständnis verbessert.
  • Joseph Pelrine ist dafür verantwortlich, dass ich noch etwas über Teamdynamik gelernt habe: Hochproduktive Teams kochen.
  • Von einem Kunden habe ich mich belehren lassen, was die mögliche Produktivität verteilter Teams anbelangt.
  • Ein ganz kleines bisschen Perl habe ich gelernt. Und zumindest für kleine Skripte kann ich nicht erkennen, was an Perl schlecht sein soll.
  • In einem Projekt habe ich Selenium RC eingesetzt und den designierten Nachfolger Google Web-Driver.
  • Ich habe meine Rails-Kenntnisse deutlich vertieft. Dazu habe ich das Buch Rapid Web Development mit Ruby on Rails gelesen. Das ist nicht mehr ganz aktuell, aber ich hatte es ohnehin noch im Bücherregal stehen und für einen Überblick war es OK. Anschließend habe ich begonnen, eine echte (kleine) Anwendung in Rails zu programmieren und bin davon ganz angetan. Nur mit der Installtion unter Ubuntu hatte ich anfänglich einige Probleme.
  • Im Rails-Zusammenhang habe ich mich auch mit RSpec, Cucumber und Webrat beschäftigt. Auch das sieht für mich alles sehr schön und elegant aus. Das Oberflächentesten mit Webrat ist z.B. sehr schön einfach und schnell.
  • Bei einem Kunden habe ich mich etwas mit TestNG beschäftigt. Naja. Für TDD kann ich gegenüber JUnit keine Vorteile erkennen.
  • Ich habe mit dem Buch SOA in Praxis ein weiteres Buch aus dem Regal geholt, dass dort schon eine Weile stand. Mein Review dazu habe ich im Blog beschrieben. Das Buch war durchaus lohnenswert, auch wenn ich kein SOA-Fan bin.
  • Bei einem Kunden durfte ich erleben, wie Kanban in der Praxis eingesetzt wurde – zumindest anfänglich auch mit interessanten Schwierigkeiten.
  • Neben CSM-Kursen biete ich inzwischen auch CSPO-Kurse an. Bei der Vorbereitung des CSPO-Kurses habe ich viele Dinge über Product-Owner-Arbeit reflektiert und neu gelernt.
  • Und zum Beweis, dass ich noch nicht vollkommen Plem-Plem bin, habe ich auch etwas im Bereich außerhalb der IT gemacht. Ich habe beim Windsurfen Racejibe und Sinkerwende gelernt. OK, Racejibe geht bisher nur rechtsrum, aber das wird noch. Ich hoffe, auf einen milden und windreichen Jahresausklang.
  • Und dann habe ich mir von meinem kleinen Bruder zeigen lassen, wie Brustschwimmen und Kraulen richtig funktioniert. Und siehe da: Das einzige, was ich bisher richtig gemacht habe, dass ich eine Badehose anhatte. Immerhin erklärt es, warum ich so ein schlechter Schwimmer bin. Jetzt muss ich die richtige Technik “nur” noch üben.

Damit habe ich von dem, was ich mir für das dritte Quartal vorgenommen habe, fast alles geschafft. Nur Scala habe ich mir nicht angesehen. Ich fand es dann doch spannender einfach Rails zu programmieren und aus demselben Grund werde ich wahrscheinlich auch im vierten Quartal nicht dazu kommen, mir Scala anzusehen.

October 14, 2009 at 5:45 pm Leave a comment

XP-Days Germany am 26-28.11.09 in Karlsruhe

XP Days Germany ist die größte deutschsprachige Konferenz zur agilen Softwareentwicklung. Sie findet dieses Jahr vom 26. bis 28. November in Karlsruhe statt.

Einige Highlights:

  • Keynote von Alistair Cockburn
  • Zwei Halbtagestutorials mit begrenzter Teilnehmerzahl
  • Vier parallele Tracks am Hauptkonferenztag
  • Mehrere Pecha-Kucha-Blöcke
  • Community Day mit Open Space und World Cafe

Das detaillierte Programm,den Link zur Anmeldung und zahlreiche weitere Informationen gibt es auf http://www.xpdays.de

Laufende Neuigkeiten über Teilnehmerzahlen, freie Plätze, Programmänderungen etc. werden über Twitter verbreitet. Informationen dazu gibt es hier: http://xpdays.de/2009/twitter.html

Ich selbst werde mit einem Vortrag zum inkrementellen Entwurf und einem Pecha-Kucha-Vortrag zu Stop-the-Line vertreten sein.

Ich hoffe, wir sehen uns auf den XP-Days.

September 18, 2009 at 8:17 am 1 comment

Older Posts