I coded the “Roman numeral kata” for the first time last night. I thought it was a reasonably straightforward exercise, but then I looked at the solutions of others by searching the web.
In agile, there’s this notion of “doing the simplest thing that could possibly work,” and I think it applies to TDD just fine. It helps keep me in the red-green-refactor rhythm. More importantly, it prevents me from pre-building complexity. It also keeps me in a mode of extreme incrementalism: DSTTCPW keeps teaching me how to truly grow a system incrementally, as agile demands.
From looking at the solutions on the web, however, I suspect that some people translate “do the simplest thing” to “don’t think at all.” Specifically, I’m referring to their progression of tests. At all times, once I complete a single test method, I spend some time thinking about what the next test should be. I don’t spend too much time, but nor do I blindly jump into the next apparently obvious test.
The task in the Roman numeral kata is to convert a positive integer to a Roman numeral. Doing this kata in a TDD fashion, the first test is converting 1 to I, which is a hard-coded return. The second test is converting 2 to II, which is simply done with an if statement. One might refactor at this step to a loop/count construct, or one might wait until 3 (III).
From 3, though, I noted that many of the coders insisted on jumping directly to 4 (IV). Certainly, this works, but most of the solutions I saw derived in this fashion either ended up more complex, or resulted in a fairly excessive solution that scaled back dramatically with some last-step refactoring.
One could argue that this is in the true spirit of incrementalism. After all, we should be able to tackle requirements in any order. Perhaps we need only support the numbers 1 through 4 initially, and later someone will insist on adding 5+.
An argument currently brewing on the XP list goes into the whole YAGNI thing, with one poster suggesting that if you have comprehensive information, there is nothing wrong with taking that into account. Kent Beck subsequently updated his take on YAGNI: “Here’s what I do: consider [forthcoming feature] a little, but try not to get so caught up in it that I freeze.”
In a similar fashion, TDD doesn’t mean “don’t think.” Determining the next test to write should incorporate some thought about what represents the simpler path to a more complete solution. Sometimes this is a guess, but with more experience, the wiser choices are more apparent. Sometimes you make the wrong choice, but you can still end up in the right place, particularly if you refactor with diligence.
With respect to the Roman numeral solution, the better answer is, try 5 (V) before 4 (IV). Then add combinations of V and I (6, 7); then finalize this logic with X, which pretty much demands a table-driven solution.
A last intuitive leap can dramatically improve the solution, but is not essential: Table entries don’t have to represent a single Roman letter. Thus you end up with an entry in the table for 4 (IV), 9 (IX), 40 (XL), 90 (XC), and so on. The logic stays clean and simple:
import java.util.*;
public class Roman {
private final int number;
private static final TreeMap<Integer, String> digits = new TreeMap<Integer, String>();
{
digits.put(1, "I");
digits.put(4, "IV");
digits.put(5, "V");
digits.put(9, "IX");
digits.put(10, "X");
digits.put(40, "XL");
digits.put(50, "L");
digits.put(90, "XC");
digits.put(100, "C");
digits.put(400, "CD");
digits.put(500, "D");
digits.put(900, "CM");
digits.put(1000, "M");
}
public Roman(int number) {
this.number = number;
}
@Override
public String toString() {
StringBuilder roman = new StringBuilder();
int remaining = number;
for (Map.Entry<Integer,String> entry: digits.descendingMap().entrySet()) {
int decimalDigit = entry.getKey();
String romanDigit = entry.getValue();
while (remaining >= decimalDigit) {
roman.append(romanDigit);
remaining -= decimalDigit;
}
}
return roman.toString();
}
}
If you don’t make the intuitive leap, the final solution is a bit more muddy (as I saw in a few solutions out there). But you have a second chance: Since you have all those wonderful tests, you can refactor the heck out of your muddy solution, looking for a more concise expression, and often you’ll find it.
