~ $ cd craft/kata && cat README.md

The kata,
one commit
at a time.

Robert C. Martin wrote the Bowling Game Kata to be repeated like a form, until its steps come without thinking. This is it in JavaScript, as I taught it, split into the commits a student makes: each one a single move — a test, the code it asks for, or a clean-up — and the bar says whether the tests passed. Every commit is run here, in the page, as you reach it: walk it with the arrows, or jump from the strip. Where one of my essays says something about a step, it is beside it, with a link to where I say it at length.

What to watch

The rhythm. Red, then green, then as many clean steps as it takes, all of them green. The strip at the top is that rhythm, seen before a line of it is read.

Refactor only after it works. The duplication in the tests is marked at commit 8, and it waits: nothing is cleaned while a test fails. At 17 the spare test fails, and the design is wrong for it — the slide says so. So the next commit sets the test aside, and the design changes with every test passing. The test comes back, is set aside once more when the design is still wrong, and passes at 28.

Add new code before removing the old. Commit 10 creates a game for every test, and ignores it; only then do 11 and 12 take the old one out, one test at a time. Commits 19 to 23 do the same to the score itself, in five steps of their own.

A test seen failing once. The perfect game passes the moment it is written. A test that has never failed has not yet shown it can: so at commit 40 it expects "fail", to see it go red and show the 300 it really got, and at 41 it gets its 300 back. That step is the one I added; I wrote why in Don't Trust Tests. Since then I do it with every test that passes without asking for any code.

What else the kata taught me, I wrote down as I found it: its lessons on refactoring, part one and part two, then what to test and how to design.

Five steps, and the code works after each one

Probably the best thing the kata teaches, and it works on code of any size: how to change the way something is kept without ever breaking it. First name the parts — what keeps the data, what writes it, what reads it. Then add the new beside the old, write to both, read from the new, stop writing the old, and remove it:

export default class Game {
  _score = 0;
  roll(pins) {
    this._score += pins;
  }
  score() {
    return this._score;
  }
}

export default class Game {
  _score = 0;
  _rolls = [];
  roll(pins) {
    this._score += pins;
  }
  score() {
    return this._score;
  }
}

export default class Game {
  _score = 0;
  _rolls = [];
  roll(pins) {
    this._score += pins;
    this._rolls.push(pins);
  }
  score() {
    return this._score;
  }
}

export default class Game {
  _score = 0;
  _rolls = [];
  roll(pins) {
    this._score += pins;
    this._rolls.push(pins);
  }
  score() {
    let score = 0;
    for (let i = 0; i < this._rolls.length; i++) {
      score += this._rolls[i];
    }
    return score;
  }
}

export default class Game {
  _score = 0;
  _rolls = [];
  roll(pins) {
    this._rolls.push(pins);
  }
  score() {
    let score = 0;
    for (let i = 0; i < this._rolls.length; i++) {
      score += this._rolls[i];
    }
    return score;
  }
}

export default class Game {
  _rolls = [];
  roll(pins) {
    this._rolls.push(pins);
  }
  score() {
    let score = 0;
    for (let i = 0; i < this._rolls.length; i++) {
      score += this._rolls[i];
    }
    return score;
  }
}

After each step the code works again, so each one could be committed and merged: a large change becomes many small ones, without stopping delivery. Elsewhere this shape is called a parallel change. I wrote the technique down in Refactor Lessons Learned From The Bowling Game Kata (2/2).

Whose it is

The kata, its steps and the notes on its slides are Robert C. Martin's, from his slides of 2005. Mine are the JavaScript, the commits a student makes one by one, each labelled with its move, and the perfect game made to fail. The slides it follows are on the kata's page, with a version in Java.