TDD In Your Fingers

I’ve been pair programming with some new developers who are less familiar with Test-Driven Development, as well as giving a talk on a similar topic for the Imperial College Web Design and Software group. So after a break from hands-on programming, I’ve been doing TDD myself a lot this week, and I noticed that a lot of it is in your fingers!

TDD gives you an itchy test finger. You should run your unit tests every time you have compiling code. If this doesn’t happen very frequently – about every 1-2 minutes for my coding speed – something isn’t right, because you aren’t getting the benefit of extremely rapid feedback on the state of your code. I feel myself reaching for F11 (the Eclipse shortcut) on a regular rhythm; if I draw back this itchy finger once or twice because my code isn’t compiling at that moment, I start wondering why I haven’t got testable code and looking for ways to get there fast.

Your fingers should hurt if you have too many dependencies. For each class used by the class under test, you have to inject the dependency and then get its behaviour, either by using the real class or a mock object. Do this more than two or three times and your hands should be cramping up from all the typing. Don’t ignore it, or worse yet give up on the test; the pain is a signal that your class is too busy. Step back and figure out how to reduce the dependencies – often this involves introducing one or more additional classes.

Please pipe up if you know of other ways TDD helps keep your fingers typing good code.

My Build Is Bleeding

Ivan Moore has a possibly-clever solution to one of our currently worst problems: about half of the 18 servers that form our continuous integration service are running functional tests, and those tests are slow and getting slower. So we get exactly what Ivan describes: many people check in on what looks like a green build, and by the time it gets around to failing, we’ve no idea why it actually broke.

Is the answer lots of builds, cleverly organised as Ivan suggests to pinpoint “bad” commits? What about interactions between commits – A’s and B’s changes are OK individually, but clash when combined? To keep it all running, would I need hundreds of servers running on tens of virtualisation hosts and a new server room to put them in?

Long rows of servers receding into the distance

LSE server room. Courtesy Johnnie W@lker under a Creative Commons Attribution Generic 2.0 license (see

Or should we be trying other solutions, like a mini-build that flushes out obvious problems? Or should we just be making the $%$£*^%$*^% tests run faster already?

Stay tuned – we’re all thinking hard about the problems and Ivan is visiting us next week for a delicious lunch. I bet we’ll get to the bottom of this soon.

Testing tools that (we heard about at CITCON Europe 2008) you might find useful …

Squirrel, Paulo and I recently attended CITCON Europe 2008. Apart from meeting, discussing and solving problems with many experts in the field of continuous integration and testing, we also learnt about many testing tools. It was the first time I’ve heard of some of these tools, so I thought I’d share them with others:

Web application testing tools:

  • Selenium (we use this at youDevise) – there are various Selenium projects that aid testing of web applications. Selenium provides an IDE which allows users to record and play back tests. Tests can be stored in HTML files or in a few programming languages (Java, Ruby, Python, Perl, PHP or .Net).
  • Watir is an open-source library for automating web browsers.
  • Allors. Does something called Immersive Testing.
  • WinRunner is functional testing software for enterprise IT applications.
  • WebDriver is an open-source tool for automating web browsers.
  • Rational Robot (from IBM) is a test automation tool for functional testing of client/server applications.

Performance testing tools:

  • JMeter from Apache is a 100% pure Java desktop application designed to load-test functional behaviour and measure performance. It was originally designed for testing Web Applications but has since expanded to other test functions.
  • Grinder is a Java load testing framework that makes it easy to run a distributed test using many load-injector machines. It is freely available under a BSD-style open-source license
  • LoadRunner is a performance and load testing product by Hewlett-Packard for examining system behaviour and performance, while generating actual load.

Web Service Testing:

  • soapUI is a tool for Web Service Testing


  • Fit is a framework that allows customers to provide examples of how a program should behave. Developers then build the program and Fit verifies the program works by comparing the examples against the program.
  • FitNesse is a tool that wraps Fit, making it easier to define tests.

Get SeleniumRC Browser Windows Out of Your Way

Here’s a way to stop annoying browser windows popping up and stealing your keyboard focus when running SeleniumRC tests.

  1. Install Xephyr.
    On Fedora: $ sudo yum install xorg-x11-server-Xephyr
    On Ubuntu: $ sudo apt-get install xserver-xephyr
  2. Start Xephyr.
    $ Xephyr :1 -ac -screen 1024x768 &
  3. Open a terminal in the Xephyr xserver.
    $ DISPLAY=:1 gnome-terminal &
  4. Start a window manager in the Xephyr server.
    $ DISPLAY=:1 metacity &
  5. From the terminal within the Xephyr window start SeleniumRC server.
  6. Run your tests. Now the browser will only pop up within the Xephyr window

Browser running SeleniumRC test in Xephyr window

Xephyr is an X windowing system whose display lives entirely within…a window in another X server! See the Xephyr site for more.

Code dojo!

I’ve been wanting to do one for quite a while, but I finally got around to holding our first code dojo. It is where coders get together and engage in deliberate practice in order to improve their skills.

I’d never been to one before, and I wasn’t entirely sure how it would go. For that reason, I held it after work and made it extra, extra optional. Still, a good number of people showed up (as many as would fit in the boardroom), and it seemed to have gone pretty well.

The format I chose was the ‘Randori Kata’ with Timeboxing. Basically, we work on a problem (using Test-Driven Development and Baby Steps) in pairs. After five minutes, someone from the audience replaces one of the pair. People (other than the pair) are only allowed to give suggestions while the tests are passing (green). If they are failing (red), they are only suppose to ask questions if they don’t understand what is going on.

The problem we worked on was (more or less) minesweeper. We were to give the program a description of where the mines were, and it was to label all the spaces as either ‘mine’ or a number representing how many mines were in the area. I picked it because (a.) it looked fun and (b.) it looked simple (I didn’t want to have the first one complicated). As it turns out, it was a lot more complicated that I thought, and we didn’t finish. (I feel a bit better knowing other people doing this same problem had similar experiences).

Like I said, the response seemed good. The main feedback was that there was too much talking/distraction. We came to the consensus that we needed stricter rules enforced more strictly. Other things we noticed were:

  • Pairs weren’t talking enough – one person tended to do all the work at a time. I think this was my fault for not explaining things well enough. It started working better later.
  • Weren’t doing enough baby steps. Weren’t always doing TDD
  • The problem maybe wasn’t well suited for this style of working.
  • People moving around was kind of distracting
  • Line numbers in Eclipse would have helped a lot
  • Need to adjust Eclipse or the projector so highlighting could be seen
  • Not sure how much we used the second projector, though I still think that was wicked cool 🙂
  • Might try to get the unit tests to automatically run
  • Might like to try Extreme OO

I’m calling the experiment a success, given that at the end people were asking when the next one was.

So what do other people think? Any more suggestions for the next one?

For those who wanted them, here is the output:
Source code

As a side note, the slides were done using s5, which is made of awesome.

Code Dojo II – New Rules

We finally had our second code dojo here at yD. In short, it was another great success! I’m going to split this up into two posts, first off discussing the new rules we implemented, and second discussing the results of the evening.

For those unfamiliar with the term, a code dojo is a chance for programmers to get together and practice coding techniques. The techniques we’ve focused on have been, Test Driven Development, Pair Programming, and Baby Steps. Read more at

After our first dojo we identified some areas where we could improve the experience. So we came up with new rules with that goal in mind:

I acted as a moderator and did not participate in the coding. I was responsible for explaining the rules of the dojo, and introducing the problem. I also enforced the rules in a fairly strict manner. Since I came up with the problem, I could be the ultimate arbiter of any questions regarding the problem (generally stuff I hadn’t thought of). Everyone seemed to agree that having someone to direct the flow, and keep the rules in check was a good idea, and worked pretty well.

Our first dojo allowed questions under red bar, and suggestions under green. We determined that there tended to be too much noise, and on the whole was pretty distracting. So, we went the other way this time and allowed almost no talking at all. We did allow a simple “I don’t understand that” once under green bar. I also tried to keep the pair at the keyboard talking a lot.

Silence seemed to fit well with having a moderator. Participants were able to give comments by calling me over and whispering. These tended to be pointing out any rule breaking that I was missing. Because the pair at the keyboard talked more and the audience couldn’t help but listen; everyone in the room seemed to be on the same page in terms of the code. I don’t remember any audience member not understanding where the code was going. The silent dojo was a bit calmer overall.

Extreme OO
We tried a few of the coding rules from Object Calisthenics. These were One Dot Per Line, One Level of Indentation, and Wrap All Primitives and Strings. Of these it was really the third one that gave the most interesting results. In the end it was a really good idea. The inability to return primitives was heading towards a fairly interesting and fun design. There was perhaps a bit of an issue at the start with ‘class explosion’. Not surprisingly having a rule like this can cause a lot of classes to be created early on. Though not a bad thing, it can be a bit hard to follow for people early on. However, as the night went on it settled down quite a bit, and we were all pretty comfortable with what a Row, Column, Position, Orientation, Length and others did.

Java Specific Problem
In our first dojo, we seemed to get tripped up dealing with input and output. The problem was not exact with how the output was specified and we ended up spending some time in the land of Java Writers and Readers. I hoped to correct this by expressing the problem in more concrete Java. I provided interfaces that represented the input (a String) and the output (some void methods that were to be called under certain conditions).

I don’t know if this helped much or not. The group didn’t have any trouble this time with input or output. But, they also didn’t use the interfaces provided (they didn’t get that far). I would say this was a wash, as it didn’t hurt but didn’t add much value.

No Defined Rota
Since we’re currently hosting these dojos internally, we want everyone who attends to participate in the coding. Our first dojo we decided to do a set order in which people would be coming up to the keyboard. This time we allowed people to jump in when they wanted. I made the point at the start though that we still wanted everyone to participate, and I kept track on the board of who had gone to try to ensure some level of fairness. In the end it wasn’t an issue as everyone seemed good about going at an appropriate time and we managed to get everyone through at least twice.

Since we were trying quite a few new things, I also had an intermission at about half way into the coding. The thought was to give everyone a chance to blow off some steam since we were all forced to be quiet. I thought there might be a bit of a domain discussion at that point as well. Everyone really liked taking five minutes to discuss how things were going but it was mainly focused on the dojo itself, there was very little domain discussion. This was not a problem at all. I think we all agreed a short intermission was a good idea.

On the whole, the reaction to the changes was very positive. I felt like the night was another success. In my next post I’ll discuss more details about the problem we tackled, and where we’re going for the next dojo. Stay tuned….

Coding Dojo – Kata Calculator Story Cards

For our last two code dojos, we have done Kata Calculator. We structured it such that the coders got one requirement at a time, broken into multiple groups. Here are the story cards.

White cards

  • Calculator should be able to multiply two numbers (10 * 8 = 80)
  • Calculator should be able to operate on positive decimal numbers (2.7+1.35=4.05). Numbers less than 1 start with a leading 0.
  • Calculator should be able to add two positive integers (2+3=5)
  • Calculator should be able to subtract two numbers (6-5=1)

Red cards

  • Calculator should round all output to 10 decimal places but only display the minimum number of places to represent the number (eg, 1.2 good, 1.200 bad)
  • Calculator should be able to handle simple trigonometry operators: cosine, sine, and tangent. The number passed to the operator is in “radians” like Java’s built-in library (sin(0)=0)
  • Calculator should be able to operate on more than two numbers, assuming that precedence is left to right and that multiplication has higher precedence than addition or subtraction (3+4*5-6=17)
  • Calculator should be able to handle the constant PI. You should use “PI” as the term. (PI*0=0)

Yellow cards

  • Calculator should be able to interpret parentheses. Parentheses behave like they do in math formulas, where they “bracket” operations and operate with “highest” precedence.
  • Calculator should be able to divide numbers. Division has the same operator precedence as multiplication. (4+1/3=4.3333333333)
  • Calculator should be able to handle the summation of a series of integers, where we sum from the first number to the second number, inclusive. (sum(4,10)=49)

Blue cards

  • Calculator should handle negative numbers. A negative number is represented by an initial “-“. (7*-5)–4=-31)
  • Calculator should support an optional third parameter for the sum() function that specifies a formula to calculate for each element in the series. The character “y” is used as the formula variable. (sum(1,10,2*y)=110)
  • Calculator should handle dividing by 0, by propagating the string “NaN” to the output (6*(5/0)+4)/7=NaN)
  • Calculator should be able to handle hexadecimal input for numbers. Output remains in base 10. (5*0xAF=875)