# Lessons from the prime factorization dojo

Last week, my colleagues at Gutefrage.net, and I had our second

Coding Dojo.

I learned an important lesson â€” even though this wasnâ€™t the first time I practiced the kata.

*The kata*

The task was to create a class that decomposes natural numbers into itsÂ prime factors.

Additionally, the factors should be sorted ascending.

Examples:

```
1 => [] # Since 1 is no prime ;)
5 => [5]
10 => [2,5]
75 => [3,5,5]
```

You get the idea ;)

This sounds simple and like a perfect candidate for an

Introduction to TDD, right?

Unfortunately, this kata is a bit tricky.

*Performing the kata*

The first tests are straightforward:

```
module PrimeFactorDecomposer
def decompose(number)
if number < 4
number
else
[2,2]
end
end
end
describe PrimeFactorDecomposer do
include PrimeFactorDecomposer
it "returns no prime factors for 1" do
decompose(1).should be_empty
end
it "decomposes 2 into 2" do
decompose(2).should be == [2]
end
it "decomposes 3 into 3" do
decompose(3).should be == [3]
end
it "decomposes 4 into 2,2" do
decompose(4).should be == [2,2]
end
end
```

Now decomposing 5 would be a nice test? Right? Since 5 is a prime, it would only return 5. But how can we find out if itâ€™s a prime?

So, we could write a function that finds out if 5 is prime. Hm, that seems hard.

What about 6? But then we have to develop an algorithm that works â€” otherwise, we would just move sidewards and add conditionals.

*Whatâ€™s the problem?*

You do not know how to solve the problem. Not everything is as simple as theÂ FizzBuzzÂ Kata.

Adding another test alone does not suffice. Itâ€™s a common hurdle for newcomers to TDD.

*How to solve this?*

Grab a sheet of paper and think about the algorithm. Or do a little spike until you fully understand the problem. Every so often itâ€™s just not true, that a design â€śmagicallyâ€ť emerges.

*Learnings*

You need sound knowledge about where to go â€” otherwise you will have problems with TDD along the way. Then you have to lean back and think a little or get feedback from something else than your tests.

TDD is cool, but it cannot solve every problem. Especially not complicated algorithms (this is a straightforward one, of course).

Another personal learning for me was to watch myself better, when I do a kata the first time.

When the design does not emerge from the tests â€” I should listen to them. Maybe they want to tell me that I have absolutely no idea what I am doing and that I need to think moreâ€¦