I decided not to look into the instructions provided with the Kata, instead focusing on reverse engineering the code. Indeed, I have much more often faced codebases with no documentation and nobody around that understood what it did, or how it did it, than codebases that were explained to me.
I started with the simplest end to end test I could come up with:
cargo run > correct_output.txt- simple shell script to diff
cargo run's output with the saved output cargo watch -s ./e2e.sh -i result.txtto hot-reload after every change That gave me the confidence to start making changes and catch most issues. It would show that things went wrong, but not really pin-point the issues.
After that, I started identifying patterns, one after the other.
- Quality cannot go over 50 -> extract a couple of unit tests and a simple method that only increases quality if it's <50
- Quality cannot go under 0 -> same
- Understand everything that happens with one item after the other (I did ETC concert tickets -> Aged Brie -> Sulfuras -> any other item). For each one of them, I would understand case by case what happened, by writing unit tests for them. After writing enough tests, I would extract all code related to one item (e.g. Aged Brie) into a match pattern branch, until the tests passed
- After having extracted all the individual paths, I was able to understand the code better and improve the code further (remove duplicates, simplify branches, cover more cases with tests as I understood the "business rules").
I ran the tests on each save with cargo watch -x test, to use my tests as much as I could to help me refactor faster and more effectively.
I could have decided to refactor further and use traits, and overwrite the "update_quality" and "update_sell_in" functions. I opted against it because I felt it was too early to optimise, and would - for now - make the code less readable. With more items in play, the traits approach becomes more and more interesting.
This Kata was originally created by Terry Hughes (http://twitter.com/TerryHughes). It is already on GitHub here. See also Bobby Johnson's description of the kata.
As Bobby Johnson points out in his article "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.
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. A while back I wrote this article "Writing Good Tests for the Gilded Rose Kata" about how you could use this kata in a coding dojo.
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" 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 "Text-Based" tests provided in this repository. (Read more about that in the next section)
Whichever testing approach you choose, 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 designing tests, taking small steps, running the tests often, and incrementally improving the design.
This code comes with comprehensive tests that use this approach. For information about how to run them, see the texttests README
More translations are most welcome! I'm very open for pull requests that translate the starting position into additional languages.
Please note a translation should ideally include:
- a translation of the production code for 'update_quality' and Item
- one failing unit test complaining that "fixme" != "foo"
- a TextTest fixture, ie a command-line program that runs update_quality on the sample data for the number of days specified.
Please don't write too much code in the starting position or add too many unit tests. The idea with the one failing unit test is to tempt people to work out how to fix it, discover it wasn't that hard, and now they understand what this test is doing they realize they can improve it.
If your programming language doesn't have an easy way to add a command-line interface, then the TextTest fixture is probably not necessary.
I analysed this repo according to the clean code standards on Better Code Hub just to get an independent opinion of how bad the code is. Perhaps unsurprisingly, the compliance score is low!