## File: README.md

_Support this and all my katas via [Patreon](https://www.patreon.com/EmilyBache)_

# Gilded Rose Refactoring Kata

You can find out more about this exercise in my YouTube video [Why Developers LOVE The Gilded Rose Kata](https://youtu.be/Mt4XpGxigT4). I also have a video of a worked solution in Java - [Gilded Rose Kata, Hands-on](https://youtu.be/OdnV8hc9L7I)

I use this kata as part of my work as a technical coach. I wrote a lot about the coaching method I use in this book [Technical Agile Coaching with the Samman method](https://leanpub.com/techagilecoach). A while back I wrote this article ["Writing Good Tests for the Gilded Rose Kata"](http://coding-is-like-cooking.info/2013/03/writing-good-tests-for-the-gilded-rose-kata/) about how you could use this kata in a [coding dojo](https://leanpub.com/codingdojohandbook).


## How to use this Kata

The simplest way is to just clone the code and start hacking away improving the design. You'll want to look at the ["Gilded Rose Requirements"](https://github.com/emilybache/GildedRose-Refactoring-Kata/blob/main/GildedRoseRequirements.md) which explains what the code is for. I strongly advise you that you'll also need some tests if you want to make sure you don't break the code while you refactor.

You could write some unit tests yourself, using the requirements to identify suitable test cases. I've provided a failing unit test in a popular test framework as a starting point for most languages.

Alternatively, use the Approval tests provided in this repository. (Read more about that in the section "Text-based Approval Testing").

The idea of the exercise is to do some deliberate practice, and improve your skills at designing test cases and refactoring. The idea is not to re-write the code from scratch, but rather to practice taking small steps, running the tests often, and incrementally improving the design. 

### Gilded Rose Requirements in other languages 

- [English](GildedRoseRequirements.md)
- [Español](GildedRoseRequirements_es.md)
- [Français](GildedRoseRequirements_fr.md)
- [Italiano](GildedRoseRequirements_it.md)
- [日本語](GildedRoseRequirements_jp.md)
- [Português](GildedRoseRequirements_pt-BR.md)
- [Русский](GildedRoseRequirements_ru.md)
- [Українська](GildedRoseRequirements_ua.md)
- [ไทย](GildedRoseRequirements_th.md)
- [中文](GildedRoseRequirements_zh.txt)
- [한국어](GildedRoseRequirements_kr.md)
- [German](GildedRoseRequirements_de.md)
- [Euskara](GildedRoseRequirements_eu.md)
- [Galego](GildedRoseRequirements_gl.md)

## Text-Based Approval Testing

Most language versions of this code have a [TextTest](https://texttest.org) fixture for Approval testing. For information about this, see the [TextTests README](https://github.com/emilybache/GildedRose-Refactoring-Kata/tree/main/texttests)

## History of the exercise

This Kata was originally created by Terry Hughes (http://twitter.com/TerryHughes). It is already on GitHub [here](https://github.com/NotMyself/GildedRose). Bobby Johnson described the kata in an article titled "Refactor This: The Gilded Rose Kata", but unfortunately it is no longer on the internet. I found it on the Wayback Machine [here](https://web.archive.org/web/20240525015111/https://iamnotmyself.com/refactor-this-the-gilded-rose-kata/).

I translated the original C# into a few other languages, (with a little help from my friends!), and slightly changed the starting position. This means I've actually done a small amount of refactoring already compared with the original form of the kata, and made it easier to get going with writing tests by giving you one failing unit test to start with. I also added test fixtures for Text-Based approval testing with TextTest (see [the TextTests](https://github.com/emilybache/GildedRose-Refactoring-Kata/tree/main/texttests))

As Bobby Johnson points out in his article "Why Most Solutions to Gilded Rose Miss The Bigger Picture" (on the Wayback Machine [here](https://web.archive.org/web/20230530152324/https://iamnotmyself.com/why-most-solutions-to-gilded-rose-miss-the-bigger-picture/)), it'll actually give you
better practice at handling a legacy code situation if you do this Kata in the original C#. However, I think this kata
is also really useful for practicing writing good tests using different frameworks and approaches, and the small changes I've made help with that. I think it's also interesting to compare what the refactored code and tests look like in different programming languages.

## Contributing

I have been struggling for some time with the maintenance burden for the Gilded Rose respository. I get frequent spurious pull requests from people who have been assigned to work on it as an exercise by some other organization (I don't know who) and mistakenly send me a pull request with their solution. I get so many of these it's a significant amount of work to check that they aren't a legitimate contribution. It's really annoying. I have sadly now added a restriction now so that only prior contributors can now open issues, comment, or create pull requests.

If you would like to make an actual contribution that improves the starting position of the exercise, please see [CONTRIBUTING.md](./CONTRIBUTING.md) for some ideas about how to get involved.

---

## File: abap/README.md

# Gilded Rose Refactoring Kata in [ABAP](http://scn.sap.com/community/abap/)

## Prerequisite

Access to SAP NetWeaver server with at least ABAP 7.40

## Installation

Assuming you have a proper developer key set up, run SE38
* create a new Module Pool (type M) program as a Local Object
* paste the raw code from [YY_PAO_GILDED_ROSE.abap](https://raw.githubusercontent.com/brehberg/GildedRose-Refactoring-Kata/master/abap/YY_PAO_GILDED_ROSE.abap)
* save (Ctrl-S) and activate (Ctrl-F3) the program

## Running Tests

From the menus choose Program -> Execute -> Unit Tests (Ctrl+Shift+F10)

---

## File: bash/README.md

# Requirements

`bash` and friends (`diff`, `grep`, `cat`)

# (Failing) Unit Test

```shell
./unit_test.sh
```

# Texttest Fixture

```shell
./texttest_fixture.sh
```

Specify days:

```shell
./texttest_fixture.sh 30
```

Verify againt `ThirtyDays/stdout.gr`

```shell
./verify.sh
```

## BTW

BTW, the script is a pure "function", so this works:

```shell
$ echo -e 'Aged Brie|3|5\nOther Item|4|5' |
> ./gilded_rose.sh |
> ./gilded_rose.sh |
> ./gilded_rose.sh
Aged Brie|0|8
Other Item|1|2
```

---

## File: c_cmocka/README.md

# Gilded Rose starting position in C with CMocka

Use CMake to build it. Run the target "sample_test" to run the sample unit test using the cmocka framework.

## Run the TextTest fixture on the command line

When you build this project this executable should be created:

    c_cmocka/cmake-build-debug/main

Execute it on the command line with an argument for the number of days:

    c_cmocka/cmake-build-debug/main 10

## Run the TextTest approval test that comes with this project

There are instructions in the [TextTest Readme](../texttests/README.md) for setting up TextTest. You will need to specify the C executable in [config.gr](../texttests/config.gr). Uncomment this line to use it:

    executable:${TEXTTEST_HOME}/c_cmocka/cmake-build-debug/main

---

## File: c99/README.md

# Gilded Rose, C99 Edition

The command "make" will build and run your tests, as well as build the program
golden_rose, which can serve as the basis for a golden-rule test.


## Assumptions
  - gnu make and a C compiler (like gcc) is installed on your system and is in the PATH
  - The check unit testing library is installed on your system (https://libcheck.github.io/check/)
  - pkg-config is installed on your system

## Usage
  - Run `make` to build the program and run all tests
  - Files which contain tests should be named `test_*.c`  They will automatically
    be included in your test suite.
  - `GildedRose.h` should not be modified.  The Goblin threat is real.
  - New program logic may be included in files named `gilded_*.c` which will
    automatically be included in both your tests and the final program.

## Golden Rule tests
  - The program `golden_rose` will generate text output.  If you capture this
    output after your first `make` you can use this as a reference for a golden
    rule test.
  - You can test your work against this reference by directing the output of your
    current golden_rose to a file and using the `diff` utility to compare that
    to the reference file you created above.
  - To avoid the Goblin threat you can use `git diff GildedRose.h`, which should
    have no output if you have left the precious Item structure unchanged.

## Notes
  - This project is tweaked to run on Linux systems, and will mostly work on Macs.
    With some changes to the Makefile it can be made to run on BSD systems with
    BSD make.  An adventurous person could also get it to run on Windows.
  - If you are working on a Macintosh computer you cannot run the memtest target,
    because valgrind and OS X don't play nice any more.  If you want to use the
    memory checker OS X does run docker as a first class citizen.
  - If you don't have pkg-config on your system, the only changes you'll need to
    make are for the requirements of the check library.  Mostly you need to
    set the appropriate flags for threaded binaries, which may include some
    special linker flags.  The libcheck documentation will cover what you need
    if you want to undertake this change.

---

## File: clojure/README.md

# Gilded Rose

This is the Gilded Rose kata in Clojure.

## Getting started

You'll need the [clojure command-line tool](https://clojure.org/guides/install_clojure).

## Running app

Produces output suitable for texttests:

```sh
clojure -M:main
```

You can specify the number of days as args:
```sh
clojure -M:main 31
```

## Running tests

To run all tests

```sh
clojure -M:test
```

To run all tests in watch mode

```sh
clojure -M:test --watch
```

---

## File: common-lisp-parachute/README.md

# gilded rose

The requirements of gilded rose can be found here:
https://github.com/emilybache/GildedRose-Refactoring-Kata/blob/main/GildedRoseRequirements.txt

# Setup

## Install quicklisp

To run this project install quicklisp (if not already done): 
 - download https://beta.quicklisp.org/quicklisp.lisp
 - load it with your common lisp implementation. The example with sbcl: 
   > sbcl --load quicklisp.lisp
 - run the command 
   > (quicklisp-quickstart:install) 
   in your common lisp implementation
 - run the command 
   > (ql:add-to-init-file) 
   in your common lisp implementation

## Install project
Copy the project-folder containing this file into /quicklisp/local-projects/ that has been created when installing quicklisp.
This is the root directory for quicklisp to search for the gilded-rose.asd file which defines the system (project) and its dependencies.
The quicklisp-folder is usually created in your home-directory.

## Working with the project

Now you can load the project with 
> (ql:quickload "gilded-rose") 
in the common lisp implementation of your choice and run the tests with 
> (asdf:test-system "gilded-rose")
.

If you just want to run the tests
> (asdf:test-system "gilded-rose")
is sufficient.

You can mock functions and methods with the cl-mock-library which is already included in the system definition of the test-system:

(with-mocks ()
  (answer <your-method> (call-previous))
  (<your-method> <argument-list>)
  (is <your-testcase> (invocations '<your-method>)))
  
If you just want to stub functions you can replace 
(call-previous) 
with a return value of your choice and your test does not depend on 
(invocations '<your-method>)

## Running the texttest-fixture

If you don't want to work with the unit-tests you can test your program with the texttest-fixture.
After loading the project in the common lisp implementation of your choice with
> (ql:quickload "gilded-rose")
you can run the texttest-fixture with
> (gilded-rose::run-gilded-rose <number-of-days>)
where <number-of-days> is the number of days you want to simulate.

---

## File: cpp/README.md

# C++ version of Gilded Rose refactoring kata

## Introduction
The C++ version of the Gilded Rose refactoring kata is available in four variants using different test frameworks:

* Catch2 test framework
  1. Traditional unit test with the [Catch2](https://github.com/catchorg/Catch2) test framework in the `test/cpp_catch2_unittest` folder.
  2. [Approval tests](https://github.com/approvals/ApprovalTests.cpp) with the [Catch2](https://github.com/catchorg/Catch2) test framework in the `test/cpp_catch2_approvaltest` folder.
* GoogleTest framework
  1. Traditional unit test with the [GoogleTest](https://github.com/google/googletest) test framework in the `test/cpp_googletest_unittest` folder.
  2. [Approval tests](https://github.com/approvals/ApprovalTests.cpp) with the [GoogleTest](https://github.com/google/googletest) test framework in the `test/cpp_googletest_approvaltest` folder.

The `GildedRose.cc` file, i.e. the code under test, is identical in all four variants.

## Prerequisites

* CMake version &GreaterEqual; 3.13
* C++ compiler that supports C++14 

## How to build and run tests in a terminal

### Build tests

    $ cd ${GIT_FOLDER}/GildedRose-Refactoring-Kata/cpp
    $ mkdir build
    $ cd build
    $ cmake ..
    $ cmake --build .

The following test specific options for building with CMake are available.

* `BUILD_APPROVAL_TESTS_WITH_CATCH2:BOOL=ON`
This option builds the approval tests with the Catch2 test framework.
* `BUILD_UNIT_TESTS_WITH_CATCH2:BOOL=ON`
This option builds the unit tests with the Catch2 test framework.
* `BUILD_APPROVAL_TESTS_WITH_GTEST:BOOL=ON`
This option builds the approval tests with the GoogleTest test framework.
* `BUILD_UNIT_TESTS_WITH_GTEST:BOOL=ON`
This option builds the unit tests with the GoogleTest test framework.

For example, run the CMake configuration `cmake -DBUILD_APPROVAL_TESTS_WITH_CATCH2=OFF -DBUILD_UNIT_TESTS_WITH_CATCH2=OFF ..` to disable the Catch2 based tests.

### Show available tests

    $ cd ${GIT_FOLDER}/GildedRose-Refactoring-Kata/cpp/build
    $ ctest -N
    Test project ${GIT_FOLDER}/GildedRose-Refactoring-Kata/cpp/build
      Test #1: GildedRoseCatch2ApprovalTests
      Test #2: GildedRoseCatch2UnitTests
      Test #3: GildedRoseGoogletestApprovalTests
      Test #4: GildedRoseGoogletestUnitTests

### Run all tests

    $ ctest

### Run all tests with verbose output

    $ ctest -VV

### Run a specific test with verbose output

    $ ctest -VV --tests-regex Catch2Approval

## How to build and run tests using the [CLion IDE](https://www.jetbrains.com/clion/)

1. Start CLion
2. Select menu `File - Open...`
3. Select folder `${GIT_FOLDER}/GildedRose-Refactoring-Kata/cpp`
4. Select menu `Build - Build Project`
5. Select menu `Run - Run...`
6. Select what test variant to run, e.g. `GildedRoseCatch2ApprovalTests`.

## How to build and run tests using Visual Studio &GreaterEqual; 2019 

1. Start Visual Studio
2. Select `Open a local folder`
3. Select folder `${GIT_FOLDER}/GildedRose-Refactoring-Kata/cpp`
4. Wait for message `CMake generation finished.` in the CMake output window at the bottom
5. Select what test variant to run in the drop down menu for Startup Items, e.g. `GildedRoseCatch2ApprovalTests.exe`.
6. Select menu `Debug - Start`

---

## File: csharp.NUnit/README.md

# Gilded Rose starting position in C# NUnit

## Build the project

Use your normal build tools to build the projects in Debug mode.
For example, you can use the `dotnet` command line tool:

``` cmd
dotnet build GildedRose.sln -c Debug
```

## Run the Gilded Rose Command-Line program

For e.g. 10 days:

``` cmd
GildedRose/bin/Debug/net8.0/GildedRose 10
```

## Run all the unit tests

``` cmd
dotnet test
```

---

## File: csharp.xUnit/README.md

# Gilded Rose starting position in C# xUnit

## Build the project

Use your normal build tools to build the projects in Debug mode.
For example, you can use the `dotnet` command line tool:

``` cmd
dotnet build GildedRose.sln -c Debug
```

## Run the Gilded Rose Command-Line program

For e.g. 10 days:

``` cmd
GildedRose/bin/Debug/net8.0/GildedRose 10
```

## Run all the unit tests

``` cmd
dotnet test
```