The prime factors kata is popularised by Uncle Bob (Robert C. Martin). He is well known for his championing of Test Driven Development (TDD) and clean code. Uncle Bob often uses the prime factors kata to explain the power of TDD. The kata is interesting, because it shows the power of incremental steps. Every test you introduce will fine tune the algorithm until finally a working factorisation algorithm emerges. If you follow the rules of TDD it can sometimes feel as if the algorithm arrives out of thin air.

I would recommend performing this kata yourself before you continue reading. The best way to do the kata is by taking incremental steps like this:

1. The number 1 returns an empty list of factors
2. The number 2 returns a list with the factor 2
3. The number 3 returns a list with the factor 3
4. The number 4 returns a list of the factors 2 and 2
5. Etc

For every new number you only make the minimum changes to pass the test. After a few steps you will notice the algorithm becomes better and better and more and more tests start passing without any code changes. You can follow these steps until a fully working algorithm emerges.

If you have no experience with TDD, I would recommend to read the introduction article: Test driven development: red, green, refactor. After trying the kata you can continue in this article to see how I would solve the kata.

Last week we worked through the String Calculator kata. The goal of this kata was to use Test Driven Development (TDD) to develop a function that could calculate the sum of a string of numbers separated by commas, newlines or a user defined delimiter. We stopped the article after the first five requirements, but there are more advanced requirements. In this article we will walk through the advanced requirements step by step and I will show you how you can implement them using TDD.

I would recommend to read the previous article first. This article builds on the code we wrote in the that article. The code we will start off with is available at Github.

Practising our Test Driven Development (TDD) skill is always a good idea. While we can use our work projects to practice it can be more effective to also do some Katas to teach yourself specific skills that you might not need every day in your normal work. An example of such a skill is string manipulation. It is a useful skill to have, especially in a TDD context, but it isn't something you need every day. This is where the String Calculator Kata comes in.

In the String Calculator Kata you build an application that can read a string of numbers and calculate the sum of these numbers. The goal of the kata is to practice Test First, refactoring and string manipulation skills. The Kata is a bit more advanced than the FizzBuzz kata and Greeter kata I discussed before. And if you are less familiar with TDD or PHP, I would recommend following those articles first.

The rules of the kata are as following:

1. Create a simple String calculator with a method signature: add(string numbers) : int.
2. The method can take up to two numbers, separated by a comma and will return the sum of these numbers. For example "1" will return 1, "1,2" will return 3.
3. Allow the add method to handle an unknown amount of numbers
4. Allow a newline as a delimiter. For example "1\n2" should return 3, but also "1\n2,3" should work and return 6
5. Allow to change the delimiter. The begin of the string contains a separate line starting with //[delimiter]. For example "//;\n1;2" should return 3.

In this article we will stop the Kata right here. There are more steps that we can add to the Kata if we want to make it more advanced. We will do that in a follow up article.

In the next chapters I will describe how to walk through the Kata using the Red, Green, Refactor technique, but before you read further I would recommend that you try the Kata yourself first. You learn most by practising for yourself before reading a possible answer. Of course, after you tried the kata, it can be useful to follow along. There are multiple solutions to the Kata and by trying different possibilities you learn the most.

Test Driven Development (TDD) is a skill that needs practice. While we can practice and improve our skills in our work projects, a kata can be useful improve a specific skill. Today we will focus on the Greeter kata. In the Greeter kata we will build an application that greets the user based on the time of the day: good evening, good night, good morning, etc. The goal of this kata is to practice delegation and refactoring. To make our tests repeatable we need to make them independent of time. We can do that by delegating the handling of time to a different object that we can control from the test.

The rules of the greeter kata are:

1. Write a Greeter class with a greet method that receives a name and returns Hello <name>.
2. You aren't allowed to change the method signature during the kata
3. Greet removes spaces at the begin and end of a name
4. Greet capitalises the name
5. Greet returns Good morning <name> between 06.00 and 12.00
6. Greet returns Good evening <name> between 18.00 and 22.00
7. Greet returns Good night <name> between 22.00 and 06.00

I would recommend to try the kata for yourself before you continue reading. In the rest of the article I will give a step by step guide how to walk through this kata. If you don't have any experience with TDD or katas, I would recommend to read my introduction article: Test Driven Development: Red, Green, Refactor.

Test Driven Development (TDD) is a software design technique where you use tests to drive your design. A generally used technique is the Red, Green, Refactor technique. You start with writing a failing test: Red. Then you write just enough production code to make the test pass: Green. And when the tests are green you have the opportunity to refactor both your tests and your production code.

The advantage of first writing a test, before writing your production code, is that you always saw your test fail before you make it pass. This gives you some confidence that the test works. When you write your test after your production code and you see it only pass, there might be a bug in your test that makes it always pass. As you get more confidence in your tests, you can start refactoring in the refactoring stage much more confidently.