• Articles
    • Popular
  • Katas
    • Get Started
  • Subscribe
  • Github Sign in with Github

Craftsmanship

Reviewed katas for software excellence
Shore_198

←Older posts
Newer posts→
New Kata

Gilded Rose Kata

Updated on Apr 23, 2013 by Todd Sedano 459
Rating:   

Challenge Level: Medium
Category: Test Driven Development
Suggested Categories: Test Driven Development

This kata fictionalizes the experience of working with someone else's code. You'll probably groan when you first see the code provided to you. The amount of code isn't overwhelming, its the prefect balance to evoke the feeling, "I can't wait to re-write this cruft." It's suggested that you use Test Driven Development with this kata. Once done, read the **spoiler** section below to see if you had a similar experience or not.

Original posting: http://iamnotmyself.com/2011/02/13/refactor-this-the-gilded-rose-kata/  

Ruby : https://github.com/professor/GildedRose

C#: https://github.com/NotMyself/GildedRose

Java : https://github.com/wouterla/GildedRose

AS3: https://github.com/dshefman/GildedRoseAS3

The Gilded Rose Kata was developed by Terry Hughes and Bobby Johnson and presented to the SC community on 2/13/2011. 

 

Kata Text

Hi and welcome to team Gilded Rose. As you know, we are a small inn with a prime location in a prominent city ran by a friendly innkeeper named Allison. We also buy and sell only the finest goods. Unfortunately, our goods are constantly degrading in quality as they approach their sell by date. We have a system in place that updates our inventory for us. It was developed by a no-nonsense type named Leeroy, who has moved on to new adventures. Your task is to add the new feature to our system so that we can begin selling a new category of items. First an introduction to our system:

  • All items have a SellIn value which denotes the number of days we have to sell the item
  • All items have a Quality value which denotes how valuable the item is
  • At the end of each day our system lowers both values for every item

Pretty simple, right? Well this is where it gets interesting:

  • Once the sell by date has passed, Quality degrades twice as fast
  • The Quality of an item is never negative
  • “Aged Brie” actually increases in Quality the older it gets
  • The Quality of an item is never more than 50
  • “Sulfuras”, being a legendary item, never has to be sold or decreases in Quality
  • “Backstage passes”, like aged brie, increases in Quality as it’s SellIn value approaches; Quality increases by 2 when there are 10 days or less and by 3 when there are 5 days or less but Quality drops to 0 after the concert

We have recently signed a supplier of conjured items. This requires an update to our system:

  • “Conjured” items degrade in Quality twice as fast as normal items

Feel free to make any changes to the UpdateQuality method and add any new code as long as everything still works correctly. However, do not alter the Item class or Items property as those belong to the goblin in the corner who will insta-rage and one-shot you as he doesn’t believe in shared code ownership (you can make the UpdateQuality method and Items property static if you like, we’ll cover for you).

 

Carnegie Mellon University - Silicon Valley campus reflections

**Spoilers** Note: you probably want to read this section after doing the kata. 

1. Most of the students thought this was a great kata for practicing TDD.

We had a great conversation about  what is the best way to test this? A few started with a given initial state and looped through update quality man times. They found that their test cases were as complicated as the code they were testing. Often this code was hard to follow or read. Many tested the individual requirements to verify that when we go from state N to state N+1, a certain invariant still holds true. 

2. What is the purpose of the Goblin rule?

(I need to find my notes on the class response to this one.) Most agreed that it was ok to subclass item provided that you didn't touch the code in the item class. Just to be sure, I asked Terry this question and here is his answer: "basically if the goblin sees anything different inside the Item class, everyone dies"

3. Of the 11 students who did it, only one refactored the code by creating subclasses of Item. (One student broke the Goblin rule and thus everyone died.)  I believe the rest did inline modifications of the original code. (Which in my opinion wasn't that hard to do, once you had the test cases written.)
 
4. We make assumptions when we write software. Some of us thought that the original code worked fine and our job was to replicate the behavior. If there was a difference between the requirement and what the code did, we assumed the code was correct. Others of us thought the opposite.
We had a great conversation about when is it appropriate for the programmer to override input given by the user? For example, Sulfuras, Hand of Ragnaros has an initial quality of 80 which violates that "The Quality of an item is never more than 50" -- some people decided to enforce this rule and drop the quality from 80 to 50 (which is ironic given that “Sulfuras never decreases in Quality" while others decided to keep the behavior of the original code. We discussed what would a considerate system do and what are circumstances where you tell the user that they are wrong.
 
5. What did you like about this kata?
-the kata was realistic and mimic a real-life scenario
-I was confident about TDD this time
-I broke the rules and modified the Item Class
-it's a good exercise for design patterns
-need to go through all the test cases
-the kata was a great way to get familiar with the syntax of a programming language
-it was also a great avenue for applying TDD and writing strong tests
-it had the perfect level of hardness to practice TDD
-code required more thought than Prime Factors. Also made me want to refactor and think in that way before starting the code.
-I liked how it demonstrated how poor readability code and make it hard to make changes
-the kata was fun because of the little story behind it. Made it more interesting than just another problem.
-I liked how the code/spec was co convoluted that it took me a while to feel confident that I had ported the code to my language correctly. It was like a brain teaser
-handling the numerous conditions and putting them efficiently in code

 

1 Reviews

1 Review

Upvote 0 Downvote

Learning TDD

Rating:    Challenge Level: Low Programming Language: Ruby
Suggested Categories: Test Driven Development    

This kata was simple, yet it gave me a decent proving ground for practicing TDD and refactoring my tests. I did this kata twice. The first time, I created a maze of code using if/else blocks to handle all of the special cases one by one. While working through the kata, I saw significant opportunities to refactor and make the code more readable. Refactoring took my update_quality method down from 51 messy lines to 18 lines of extremely readable code. I tried to refactor further to clearly define the business rules in an array or hash but found that the resultant code was less readable. I also worked to refactor my tests which had a lot of repletion in the spirit of being DRY. Although I was able to streamline my test suite down to an extremely DRY single 7 line test, I have mixed feelings about how it turned out. It's great to have a concise test suite but the tests will not be helpful since the test covers the entire code base. I think going forward, I will consider being less DRY if it gives me more granular insight into where a bug resides.


 

Updated on Apr 23, 2013 by pfeffed35

Please sign in to review.

Sign in with Github
Carnegie Mellon University - Silicon Valley
Rss-news
Powered by Hibiscus.