The Gilded Rose Kata

Code katas are little exercises that help you to improve your programming skills. My favourite one is the Gilded Rose kata. It was originally created by Terry Hughes and is now maintained by Emily Bache (@emilybache).

While most katas start from scratch, the Gilded Rose kata comes with existing code that you need to modify. This code is available for more than 40 programming languages and covers most likely your favourite language.

This short but non-trivial code makes this kata so great. You can follow along the kata and implement it as it is designed for, or you use it as a starting point for your own exercise. The possibilities are endless.

 

What is the goal?

You find all the details for the kata in the GildedRoseRequirements.txt in the root folder. You basically need to add a new requirement to an existing application.

What sounds like an easy task is all but easy. The existing application is a mess and all other requirements need to keep working. Combined with certain design limitations you end up with a great exercise in refactoring.

 

The code

The code is by design in a bad shape and offers nearly everything you will find in long running production code: a cascade of if statements, checks with inverted logic, no comments whatsoever and lots of duplicated code. This snipped is just an example and it gets worse:

 

Where to start?

Before we can implement the change, we need to understand what is going on. That most likely means refactoring the code until all the problems are gone. To make sure we do not introduce accidental changes, we need to write automated tests for the application. In the C# version of the kata we get to starting points:

• GildedRoseTest.cs where we can place our unit tests
• ApprovalTest.cs to verify the whole application using approval tests

If you prefer to write unit tests, you can do so with NUnit and a good coverage tool. It takes time but is a great exercise for writing automated tests. If you do not like NUnit, you can choose a different testing framework.

The approval test approach is much faster. You run the test and your diff tool pops up with two open files. The file ApprovalTest.ThirtyDays.received.txt contains the output of the application while ApprovalTest.ThirtyDays.approved.txt is empty:

When we copy the output into the other file (and save it!) the test will pass in the next run. Even better, the coverage report for this one test shows us that the application has a test coverage of 100%. That gives us a great safety net to do our refactoring. If we break an existing feature, the diff tool comes back up again and shows us what effect our change had on the output of the application.

Whatever approach you choose, there is a lot to clean up. When this is done you should be able to implement the change for “conjured” items in a few lines of code.

 

Conclusion

If you have 30 minutes to spare, I highly recommend trying this kata. It looks trivial until you make your first mistake in the refactoring step. From there on it is a challenge worthy of your time.