# Gilded Rose Refactoring Kata: one exercise, dozens of languages, a failing test to start

> Emily Bache's fork of Terry Hughes's kata ports deliberately ugly inventory code into dozens of languages and hands you one failing test, so the practice is refactoring under a green suite rather than rewriting from scratch.

**emilybache/GildedRose-Refactoring-Kata** — Starting code for the GildedRose Refactoring Kata in many programming languages.

- Repository: https://github.com/emilybache/GildedRose-Refactoring-Kata
- Website: https://youtu.be/Mt4XpGxigT4
- Stars: 4,302 · Forks: 6,132
- Language: XSLT
- License: MIT
- Published: 2026-10-06 · Updated: 2026-10-06 · Language: en
- Canonical page: https://hysenlabs.com/projects/emilybache-gildedrose-refactoring-kata

## A kata with a maintenance problem built into its popularity

The numbers on this repository explain the README more than the README does. It has 4290 stars and 6122 forks, so more people have copied it than starred it. That is what happens when a codebase becomes assigned homework: you clone it, you work in your own copy, and nobody ever closes the fork. GitHub reports the primary language as XSLT, which tells you how little of the repository belongs to any single ecosystem, since it is one exercise ported side by side.

Emily Bache, who maintains it, explains the consequence directly. She gets frequent spurious pull requests from people assigned the kata by some other organisation who mistakenly treat the upstream repository as the place to submit their solution. So many arrive that checking whether one is a real contribution has become a real burden, and she has restricted the repository so that only prior contributors can open issues, comment, or send pull requests.

That restriction is the clearest signal about how the project is used. Upstream is not where solutions go. If you want to be useful here, CONTRIBUTING.md lists the actual invitation, which is improving the starting position of the exercise rather than solving it.

## What the exercise actually is

The original kata was created by Terry Hughes, and it lives at a separate GitHub repository under the NotMyself account. Bobby Johnson wrote it up in an article called "Refactor This: The Gilded Rose Kata" that is no longer on the internet, and Bache recovered a copy through the Wayback Machine. His later piece, "Why Most Solutions to Gilded Rose Miss The Bigger Picture", is the more interesting read, because its argument is that solving the exercise quickly is the wrong outcome.

The README states the intent plainly. The idea is deliberate practice, and the skills being practised are designing test cases and refactoring. The idea is not to re-write the code from scratch, but to take small steps, run the tests often, and improve the design incrementally.

That single sentence explains most of the friction people hit with this kata. The tempting move is to open the file, understand the whole domain at once, and replace the offending class with a clean implementation. You will finish, the suite will be green, and you will have practised almost nothing. The requirements live in GildedRoseRequirements.md and its translations, which is the document the README tells you to read first, and it is the specification the tests are supposed to encode.

## One failing test, and why it is there

Bache's fork is not a faithful copy of the original. She translated the original C# into other languages with some help, and she slightly changed the starting position. Two consequences follow from that. She has already done a small amount of refactoring relative to the original form, and the starting code is easier to write tests against.

The concrete change is a supplied failing unit test in a popular test framework, present for most languages. It is a starting point rather than a complete suite, which means the exercise still has a test design component: the requirements document tells you what the behaviour is, and identifying the cases worth pinning down is part of the work.

Johnson's argument is that working in the original C# gives better practice for a legacy code situation, since the messier original is closer to code you inherit. Bache disagrees in part, arguing the adjusted ports are better for practising writing good tests across frameworks and approaches. Both positions are in the README, and they are not contradictory so much as a choice of what you want to practise. Doing the C# directory and a ported directory in one sitting is a cheap way to feel the difference.

## The language spread and what GitHub shows

The tree listing is the fastest way to see the scope. It runs alphabetically from Ada, C, COBOL, Delphi, Groovy and the Java family through Kotlin, Matlab, R, Smalltalk, TypeScript, TypeScript-deno, abap, bash, c99, c_cmocka, clojure, the two common Lisp directories, cpp, csharp.NUnit, csharp.xUnit, d, dart, elisp, elixir, elm, erlang, fortran, both fsharp directories, gleam, go, haskell, io and janet.

Naming is the interesting part. There are four Java directories: Java, Java-Approvals, Java-Cucumber, Java-Spock. There are two C# directories, csharp.NUnit and csharp.xUnit. There are two TypeScript directories, TypeScript and TypeScript-deno. That pattern says the same kata was ported repeatedly to demonstrate different test tooling and runtimes, not once per language.

The requirements documents follow the same thoroughness, with 17 files named GildedRoseRequirements in the tree, suffixed for Arabic, German, Spanish, Basque, French, Galician, Italian, Japanese, Korean, Dutch, Polish, Brazilian Portuguese, Russian, Thai, Ukrainian, Chinese and English. The README's own language list links 14 of those, so the repository carries a few requirement translations the README does not yet advertise. If you are teaching this exercise, that gap is worth knowing about.

## TextTest as the alternative to writing tests yourself

The second path the README offers is approval testing. Most language versions of the code ship a TextTest fixture for it, and the texttests directory has its own README. Where the failing unit test nudges you toward framework tests, TextTest takes the input and expected output as text files and compares them, which suits a domain with lots of obvious cases and not much interest in mocks.

Approval tests earn their place in this kata because the value being preserved is the output, not the internal shape. You can change the design freely while the fixture stays green, which is exactly the freedom the exercise wants you to take.

So there are two supported routes, and they exercise different muscles. Write your own unit tests using the requirements to identify suitable cases, and you practise test design. Use the fixtures, and you practise keeping a characterisation suite intact while the design moves underneath it. Bache's article "Writing Good Tests for the Gilded Rose Kata" is the long form of this argument, and the README links it alongside her dojo handbook for anyone running the kata with a group.

## Getting started, and where the README stops

The README is deliberately brief on mechanics. It says the simplest way is to clone the code and start improving the design, and then it tells you to read the requirements and get tests in place. There is no per language build matrix, no dependency pinning, and no CI configuration in the tree listing, so the run command for any given directory comes from that language's own tooling and its own ecosystem.

The clone itself is unremarkable:

```bash
git clone https://github.com/emilybache/GildedRose-Refactoring-Kata.git
cd GildedRose-Refactoring-Kata
```

Then you are inside a repository of peer directories rather than a project, and you pick one:

```bash
cd csharp.NUnit
```

What you do next depends entirely on which port you chose, and the repository will not tell you. A NuGet restore, a Gradle or Maven build, a language toolchain install, and a package manager step are all plausible depending on the directory. Expect to consult the test framework's own documentation rather than anything here.

Two things are worth reading beyond the README. Bache's book, Technical Agile Coaching with the Samman method, describes the coaching method she uses this kata inside, which is useful if you are running it with a team. Her YouTube video Why Developers LOVE The Gilded Rose Kata covers the exercise, and a second video is a worked solution in Java. Watching a solution before you start defeats the exercise, so treat that second one as something to check your own work against afterwards. The repository was last pushed on 2026-08-21, and it publishes no releases, so there is no version to pin and the working tree is the artifact.

## Conclusion

Treat Gilded Rose as a test design exercise rather than a puzzle to finish. Clone one language directory, read GildedRoseRequirements.md, run the supplied failing test before touching production code, then refactor in small steps with the suite green between every one. Emily Bache's own framing is the useful part: the original C# gives better practice for legacy code, and the slightly adjusted ports give better practice for writing tests, so the C# and csharp.NUnit directories answer different questions and are worth doing twice. The repository has been pushed to as recently as 2026-08-21, so the language list is not a finished set, and CONTRIBUTING.md is where genuine changes to the starting position go.

## FAQ

### What is the goal of the Gilded Rose exercise?

The goal is deliberate practice at designing test cases and refactoring, not a rewrite from scratch. The README says to work in small steps, run the tests often, and improve the design incrementally.

### Who created the Gilded Rose kata and who maintains this repository?

Terry Hughes created the kata, originally hosted under the NotMyself GitHub account. Emily Bache maintains this fork, having translated the original C# into many other languages and adjusted the starting position.

### Why does the repository only accept contributions from prior contributors?

Because it receives frequent pull requests from people who were assigned the kata as an exercise elsewhere and mistakenly submit their solution upstream. Emily Bache restricted issues, comments and pull requests to prior contributors because the review burden was significant.

### What tests ship with the kata?

One failing unit test in a popular test framework is provided as a starting point for most languages, plus TextTest fixtures for approval based testing in most language versions, documented in the texttests directory.

### How many programming languages does the kata cover?

The repository carries one directory per port, including Ada, C, COBOL, Fortran, Smalltalk, R, TypeScript, csharp.NUnit, csharp.xUnit, go, haskell and many more, with several languages appearing twice to show different test frameworks and runtimes.

## Sources

- [emilybache/GildedRose-Refactoring-Kata on GitHub](https://github.com/emilybache/GildedRose-Refactoring-Kata)
- [Issues](https://github.com/emilybache/GildedRose-Refactoring-Kata/issues)
- [License: MIT](https://github.com/emilybache/GildedRose-Refactoring-Kata/blob/main/LICENSE)
- [Project website](https://youtu.be/Mt4XpGxigT4)
- [README](https://github.com/emilybache/GildedRose-Refactoring-Kata/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/emilybache-gildedrose-refactoring-kata