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

Older Posts