Prime Factors Kata - First Try

This is my first try of the Prime Factors Kata. It's my first Katacast of a kata at all. I performed it with Groovy.

Stefan wrote about katas (in German) a while ago, where he described his experience as an attendee of the contest "TDD with the pros" ("TDD mit den Profis", TmdP) at the XP Days Germany 2009 in Karlsruhe. TmdP is similar to "Programming with the Stars" at Agile 2009 in Chicago, where I was an attendee of.

Stefan was in the final of TmdP with his pair partner Franziska Widmaier. Their task was to calculate all prime factors of a given number, which is the same task as in the Prime Factors Kata. Stefan and Franziska had to finish this task in less than 7 minutes - and they failed to do it in time.

Stefan and I started to work on that kata right after the XP Days ended. Our first shot was in the train from Karlsruhe back to our home town Hamburg. After that we met once via Skype and wrote each step we took during the kata. I practiced a few times per week for the last five weeks or so and showed my performance to Stefan today. He said that it'd might be time to show the result to the world, and here it is:

On Youtube:

I've also shared the Katacast on vimeo and on viddler.

My to-do list for the next try so far:

• Use a parameterized JUnit test instead of not isolated parameters in a map
• Use more of TextMate's shortcuts and optimize on a keystroke level
• Find out why 63 is too big... wtf? [Update: @datenreisender found out that this is related to a bug in Groovy.]
• [Update: @datenreisender suggested in the comments to use primefactors instead of numbers2primeFactors[number] in the assertion.]

My heartfelt thanks to Stefan, with whom it was a lot of fun preparing that kata!

Happy Christmas!

P.S.: If you want to rate my performance, then post a comment with the number 0 (very bad) to 10 (very good). This kind of rating was inspired by Micah Martin. Any additional feedback is very welcome!

[Update: Stefan Roock made a Kata Bunkai - a commented kata - for this kata. Check it out!]

Running only one of JUnit's Tests

Green Bar with only one of JUnit's Tests

I managed to run all of JUnit's tests. And I failed for some time to run only one test. Here's why and how I finally succeeded.

One test I kept a close eye on: org.junit.tests.running.classes.ParameterizedTestTest. I opened it in Eclipse and tried to run it. A window occured and asked me to select a test:

What was that? I never saw such a window before. Was it something new in Eclipse 3.5.1? I looked around and looked also into the outline of that test class:

After a closer look I thought I knew what that test selection window was all about: One was able to pick a specific test method in one test class. All of the test method names in the test selection window were also in the outline view of that class. Yes, that would make sense. And that would be actually a great thing, since it was never possibile to do that in previous Eclipse versions and that would be a very useful feature for many reasons.

Okay, new feature, cool. But how could I run one test class with all test methods together? Like I was used to do in all the previous Eclipse versions before? I asked other Eclipse users in my current project, but nobody had a clue. I asked on Twitter, and got some doubtful suggestions like "I think there is something seriously broken in your eclipse installation."

After the fifth person or so I begged for help I realized what was going on. Do you see it? It's in the pictures I showed you in this post before. What I saw after a while was this line:

What a bad UI design, I thought. Why on earth would they put an entry for the whole test class in the middle of all the other test methods? Shouldn't it at least be marked in some way? Wrong assumption, again. Those items were all test classes! Oh my, now that I look at the test selection window I see all those green icons with the C in it...

Anyhow, why are there so many static test classes (yes, that's what they are, static, and the outline view told me with a little red 'S') in one single file? Because those are the input parameters for the tests. The test class contains all the tests for JUnit's Parameterized Test feature, which is a way to deal with one test method called several times with different parameters. It's more than having a for-loop going through a bunch of parameter sets, because with JUnit's Parameterized Test feature every parameter set is treated like a separate test method. With three parameter sets you'd end up with three tests, and if one test would fail, the others won't stop running like they would do in a for-loop.

For that feature you have to provide a annotated method which should return the parameters, you have to provide a constructor and instance variables for the parameters, and you have to reference the parameters in the instance variables from within the test method. That's a lot of stuff which could be broken easily. Each static test class supports a test method for the feature. Eclipse cannot distinguish between a test class as a test class and a test class as a test input parameter, and so it showed every test class in a test selection window.

Well, maybe I shouldn't program late at night, but that was really a hard one to figure out.

Running all of JUnit's Tests

Green Bar with JUnit

After Getting JUnit from Git on a Mac I wanted to run all of JUnit's tests. Here's what happened.

First I opened the whole JUnit project in TextMate. TextMate is my editor of choice when I work with Groovy/Grails and Ruby/Rails. I do whole projects with it. For those kind of languages and frameworks Textmate is suiteable, but since JUnit is a Java project, TextMate's seems to be not enough.

I tried to run all the tests within JUnit with TextMate. There are some AllTests classes, but you can't run them from within TextMate easily, because you would have to deal with the classpath on your own. There's an Ant build file, but unfortunately without a test task. Tests seems to be only executed during a build, but I don't want to build JUnit everytime when I actually want to run all the tests.

In the build file I saw a reference to org.junit.tests.AllTests. Again, it'd be a mess to build the classpath everytime I wanted to execute the AllTests class within TextMate. I switched to Eclipse after I upgraded to Eclipse 3.5.1.

There were already project files for Eclipse in the JUnit project, so I was able to be up with JUnit in Eclipse with a simple import. I executed org.junit.tests.AllTests with Alt+CMD+X T and I saw a green bar with 481 tests. Yay!

Only the execution time wasn't that good. It took me ~23 seconds to execute all the tests, which is quite more than my expected less than 10 seconds.

At least I could run all of JUnit's tests now.

Getting JUnit from Git on a Mac

Logo of Git distributed revision control system by Wikipedia

I want to dig deeper into JUnit for some reasons. Therefore I want to see the latest version in the repository. JUnit uses Git. I use a Mac and never used Git before. Here's what I've done to get JUnit from Git on a Mac.

I installed Git for OS X. It's a dmg file and quite simple to install.

After that I had to add Git's bin path to PATH to use Git in the terminal. I added this to ~/.bash_profile.

export GIT_HOME=/usr/local/git
export PATH=$PATH:$GIT_HOME/bin

Worked now for me: I entered git in the terminal and saw a list of commands.

Now what? I read parts of the official Git tutorial online and in the terminal with git help tutorial. I entered my user.name and my email.adress as a key with git config --global key value where value is my name or email adress, because I should do that "before doing any operation".

I continued reading at paragraph "Using git for collaboration". There's what I was looking for:

Suppose that Alice [aka Kent] has started a new project with a git repository in /home/alice/project [aka git://github.com/KentBeck/junit.git as listed on github.com], and that Bob [aka me], who has a home directory on the same machine [aka ~/projects/junit], wants to contribute.

In the terminal I entered

git clone git://github.com/KentBeck/junit.git ~/projects/junit

Now Git downloaded JUnit. Finally JUnit was downloaded on my computer. The tutorial states that if Kent would commit changes I could be again up to date with a simple git pull.

So far so good to be able to have a look around in JUnit.

[Update: If you want to run Git within TextMate, than you can. TextMate can deal with Git from the start, but you have to set TM_GIT as a shell variable, e.g. to /usr/local/git/bin/git or wherever you've installed Git.]

Der grüne Pfad

soccer free zone by extranoise
gefunden über Photo Suggest

Schön, wenn einem die Arbeit abgenommen wird: Kollege Stefan Roock schreibt in seinem neuesten Blogeintrag vom grünen Pfad, den ich beim Refactoring gerne gehe. Auf einem grünen Pfad gibt es minimales Risiko, sich im Code zu verlaufen. Aber der grüne Pfad ist nicht ganz einfach zu finden, auch wenn seine Regeln sehr einfach sind:

1. Einen atomares, d.h. nicht weiter unterteilbares, Refactoring durchführen.
2. Tests grün laufen lassen.
3. Weiter mit 1.

Laufen die Tests bei 2. nicht grün, sondern rot, hat man den grünen Pfad verlassen und findet sich unweigerlich in der roten Testhölle wieder, aus der es nur durch Strg-Z oder CMD-Z einen sicheren Ausweg gibt.

Was sind atomare Refactorings? Solche, die nicht weiter durch andere Refactorings unterteilbar sind, etwa Umbenennen, Extrahieren, oder Inlinen. Die meisten anderen Refactorings sind aus atomaren Refactorings zusammen gesetzte Refactorings.

Stefan beschreibt sehr schön, dass es gar nicht darauf ankommt, immer auf dem grünen Pfad zu weilen. Eigentlich braucht man den grünen Pfad nur dann, wenn es knifflig wird. Aber wer nicht oft auf dem grünen Pfad gelaufen ist, der wird ihn nur sehr schwer finden, und wer nicht oft kleine Schritte beim Refactoring gegangen ist, der wird sich unter Druck oder in sehr krudem Big-Ball-of-Mud-Code nicht mehr daran erinnern können, also genau dann, wenn es einem besonders helfen würde.

Stefan hat ein schönes Beispiel aufgeschrieben, bei dem ich ihn quasi auf dem grünen Pfad vor mich hergeschoben habe - und er zu einer, wie ich finde, sehr cleveren Lösung gekommen ist.

Gerne gebe ich den Aufruf von Stefan weiter: Habt ihr Code, der nicht auf dem grünen Pfad zu refaktorisieren sei? Immer her damit: bernd.schiffer@gmail.com oder hier in die Kommentare. Wir freuen uns über jede Herausforderung :-)