Yeh the SubString solution certainly doesn’t work once you’ve driven out an example with 2 digit numbers but it does work if you only have single digit numbers which is what I did for my first example. It’s totally position related as you point out. If we’re building incrementally then it seems like it’s a step we should be looking to take.

I haven’t done the second part of the exercise which you describe but it does feel like the Calculator class does too much even in the state that I’ve got it in. There are a few responsibilities which don’t belong there.

Did you post up your final solution anywhere?

First of all, I will say that your SubString solution is simple, but incorrect. It relates to positional data and not the separator at all. It will choke on two digit numbers.

Then I have to agree with Michael, that the next simple step can very well be the generic solution. If you have done these kinds of things before, you better know the generic solution already.

So to my experiences with this kata: 3 times did I experience that my next test was already covered. I don’t see that as a bad thing, but as a reminder to investigate why that is.

At one point I discovered my multi-separator algorithm succeeded of the wrong reason: It treated each character as a separator, so that [*][%] was treated as 4 separators, not two, because there are 4 distinct characters present.

Introducing multi-separators was also the point where I had to rethink and refactor my approach, and I spent just as much time implementing this one test as all the previous.

At the end, with all tests passing, I had this one giant Calculator class which did more than its share of responsibilities.

The final refactoring also took nearly as much time as all the coding preceding it. The final code had more classes and looked cleaner, but if this were a real life project, I would defer the last refactoring until I actually needed to change the code.

The single calculator-class solution wasn’t that bad, but it contained a lot of small static helper methods which had nothing to do with the actual calculation.

I believe that this is the core of the argument against TDD. While some find it more natural to gradually evolve a correct solution, others prefer to reason through the whole problem and solve it once.

It is not incorrect to write a complete algorithm the first time. There is a time for evolutionary coding and a time for revolutionary coding. Each person must find their own balance.