– Few people allow themselves to write shitty code first, and it is such an efficient design tool. This is for instance a major difficulty in learning TDD – allowing yourself to just make the test pass, and quickly
– I want them to have a tool that is readily available immediately (well mostly) and the ability to refactor “after” towards OCP is easier to learn.

Maybe which approach is best depends on the person doing it, so “refactor before” could be an optional constraint. The base constraint being to refactor before next test.

So yes, in Real Work sometimes you complicate the code a bit, and then refactor. Some other times, when you find that implementing something is difficult, you first make it easier by refactoring (which might be difficult to do), and then you do it.

In a dojo context, however, if the goal is to practice creating abstractions, the rule about creating it before use is meant to force a behaviour. If you intend to create it after, you run the risk of rushing to making the next test pass, and forget to introduce the abstraction at all. So I think it can be OK to be flexible about introducing the abstraction after you need it, as long as you have a watchful moderator that will remind the learners to implement the abstractions!

Is that any clearer? I mean, the exercise is meant to help people who aren’t used to creating abstractions. If your audience has the opposite problem, then you might do better with another exercise, like e.g., the TDD As If You Meant It by Keith Braithwaite

Say I have implemented the normal accumulating bowling score and I write a test for strike.
It seems that making the test pass with a conditional like this is contrary to the rules.

if (rolls[0] === 10) {
score = sumOf3Rolls(rolls)
} else {
score = sumOf2Rolls(rolls)
}

However if I refactor right after the result is (probably) the same. And to me there are several advantages to this “refactor after” approach.

The advantages of “refactor after” are to me
– compliant to Make it work then Make it good
– easier (ok that’s a bad argument for a kata)
– builds a habit of looking at manifest mess before refactoring -> likely to lead to simpler design

So my question is what will people gain from doing it in the “refactor before” way? I tried it for quite a bit, didn’t get much from it but I suspect I might be missing something here.