mirror of
https://github.com/emilybache/GildedRose-Refactoring-Kata.git
synced 2026-02-15 22:41:30 +00:00
🔧 reorder project
simplify project structure
This commit is contained in:
parent
349889edd8
commit
8640e7a69e
@ -1,17 +0,0 @@
|
|||||||
exclude:
|
|
||||||
- /js/lib/.*
|
|
||||||
component_depth: 1
|
|
||||||
languages:
|
|
||||||
- cpp
|
|
||||||
- csharp
|
|
||||||
- go
|
|
||||||
- groovy
|
|
||||||
- java
|
|
||||||
- javascript
|
|
||||||
- perl
|
|
||||||
- php
|
|
||||||
- python
|
|
||||||
- ruby
|
|
||||||
- scala
|
|
||||||
- script
|
|
||||||
- swift
|
|
||||||
18
.gitignore
vendored
18
.gitignore
vendored
@ -1,7 +1,13 @@
|
|||||||
bin
|
.idea/
|
||||||
obj
|
|
||||||
*.sln.DotSettings.user
|
|
||||||
.vs
|
|
||||||
vendor
|
|
||||||
.idea
|
|
||||||
*.iml
|
*.iml
|
||||||
|
target/
|
||||||
|
|
||||||
|
.classpath
|
||||||
|
.project
|
||||||
|
bin/
|
||||||
|
.settings/
|
||||||
|
|
||||||
|
# Gradle
|
||||||
|
.gradle
|
||||||
|
/build/
|
||||||
|
|
||||||
|
|||||||
@ -1,38 +0,0 @@
|
|||||||
======================================
|
|
||||||
Gilded Rose Requirements Specification
|
|
||||||
======================================
|
|
||||||
|
|
||||||
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 its 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).
|
|
||||||
|
|
||||||
Just for clarification, an item can never have its Quality increase above 50, however "Sulfuras" is a
|
|
||||||
legendary item and as such its Quality is 80 and it never alters.
|
|
||||||
13
Java/.gitignore
vendored
13
Java/.gitignore
vendored
@ -1,13 +0,0 @@
|
|||||||
.idea/
|
|
||||||
*.iml
|
|
||||||
target/
|
|
||||||
|
|
||||||
.classpath
|
|
||||||
.project
|
|
||||||
bin/
|
|
||||||
.settings/
|
|
||||||
|
|
||||||
# Gradle
|
|
||||||
.gradle
|
|
||||||
/build/
|
|
||||||
|
|
||||||
@ -1,22 +0,0 @@
|
|||||||
# Gilded Rose Kata in Java
|
|
||||||
|
|
||||||
Forked version of the Gilded-Rose-Refactoring-Kate project, original can be found
|
|
||||||
[here](https://github.com/emilybache/GildedRose-Refactoring-Kata).
|
|
||||||
|
|
||||||
# Notes
|
|
||||||
|
|
||||||
## Item rules
|
|
||||||
|
|
||||||
* Quality increases or decreases when sell-in days pass or is constant.
|
|
||||||
* Quality of an item cannot be negative value.
|
|
||||||
* If item is Legendary, it's quality is always 80 and never changes.
|
|
||||||
|
|
||||||
## Types of items
|
|
||||||
|
|
||||||
| Item name | Quality changes, when day passes | Description |
|
|
||||||
|:----------|:---------------------------------|:------------- |
|
|
||||||
| Normal | **Quality decreases by 1;** <br> **Quality decreases by 2**, when sell-in date approaches | - |
|
|
||||||
| Aged Brie | **Quality increases by 1;** <br> **Quality increases by 2**, when sell-in date approaches | - |
|
|
||||||
| Conjured | <b>Quality decreases by 1;</b> <br> <b>Quality decreases by 4</b> when sell-in date approaches | - |
|
|
||||||
| Backstage Pass | <b>Quality increases by 1;</b><br> <b>Quality increases by 2</b> when there are 10 days or less;<br> <b>Quality increases by 3 </b> when there are 5 days or less;<br> <b>Quality drops to 0</b> after the concert. | - |
|
|
||||||
| Sulfura | **Always 80**. Never changes| Legendary item. Constant quality value. |
|
|
||||||
84
README.md
84
README.md
@ -1,57 +1,59 @@
|
|||||||
# Gilded Rose Refactoring Kata
|
# Gilded Rose Kata in Java
|
||||||
|
|
||||||
This Kata was originally created by Terry Hughes (http://twitter.com/TerryHughes). It is already on GitHub [here](https://github.com/NotMyself/GildedRose). See also [Bobby Johnson's description of the kata](http://iamnotmyself.com/2011/02/13/refactor-this-the-gilded-rose-kata/).
|
Forked version of the Gilded-Rose-Refactoring-Kate project, original can be found
|
||||||
|
[here](https://github.com/emilybache/GildedRose-Refactoring-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/master/texttests))
|
# Requirements
|
||||||
|
|
||||||
As Bobby Johnson points out in his article ["Why Most Solutions to Gilded Rose Miss The Bigger Picture"](http://iamnotmyself.com/2012/12/07/why-most-solutions-to-gilded-rose-miss-the-bigger-picture), it'll actually give you
|
## Gilded Rose Requirements Specification
|
||||||
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](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).
|
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:
|
||||||
|
|
||||||
## How to use this Kata
|
- 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
|
||||||
|
|
||||||
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/tree/master/GildedRoseRequirements.txt) 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.
|
Pretty simple, right? Well this is where it gets interesting:
|
||||||
|
|
||||||
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.
|
- 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 its 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
|
||||||
|
|
||||||
Alternatively, use the "Text-Based" tests provided in this repository. (Read more about that in the next section)
|
We have recently signed a supplier of conjured items. This requires an update to our system:
|
||||||
|
|
||||||
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.
|
- "Conjured" items degrade in Quality twice as fast as normal items
|
||||||
|
|
||||||
### Gilded Rose Requirements in other languages
|
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).
|
||||||
|
|
||||||
- [English](GildedRoseRequirements.txt)
|
Just for clarification, an item can never have its Quality increase above 50, however "Sulfuras" is a legendary item and
|
||||||
- [Español](GildedRoseRequirements_es.md)
|
as such its Quality is 80 and it never alters.
|
||||||
- [Français](GildedRoseRequirements_fr.md)
|
|
||||||
- [日本語](GildedRoseRequirements_jp.md)
|
|
||||||
- [Português](GildedRoseRequirements_pt-BR.md)
|
|
||||||
- [Русский](GildedRoseRequirements_ru.txt)
|
|
||||||
- [ไทย](GildedRoseRequirements_th.md)
|
|
||||||
- [中文](GildedRoseRequirements_zh.txt)
|
|
||||||
- [한국어](GildedRoseRequirements_kr.md)
|
|
||||||
|
|
||||||
## Text-Based Approval Testing
|
# Notes
|
||||||
|
|
||||||
This code comes with comprehensive tests that use this approach. For information about how to run them, see the [texttests README](https://github.com/emilybache/GildedRose-Refactoring-Kata/tree/master/texttests)
|
## Item rules
|
||||||
|
|
||||||
## Translating this code
|
* Quality increases or decreases when sell-in days pass or is constant.
|
||||||
|
* Quality of an item cannot be negative value.
|
||||||
|
* If item is Legendary, it's quality is always 80 and never changes.
|
||||||
|
|
||||||
More translations are most welcome! I'm very open for pull requests that translate the starting position into additional languages.
|
## Types of items
|
||||||
|
|
||||||
Please note a translation should ideally include:
|
| Item name | Quality changes, when day passes | Description |
|
||||||
|
|:----------|:---------------------------------|:------------- |
|
||||||
- a translation of the production code for 'update_quality' and Item
|
| Normal | **Quality decreases by 1;** <br> **Quality decreases by 2**, when sell-in date approaches | - |
|
||||||
- one failing unit test complaining that "fixme" != "foo"
|
| Aged Brie | **Quality increases by 1;** <br> **Quality increases by 2**, when sell-in date approaches | - |
|
||||||
- a TextTest fixture, ie a command-line program that runs update_quality on the sample data for the number of days specified.
|
| Conjured | <b>Quality decreases by 1;</b> <br> <b>Quality decreases by 4</b> when sell-in date approaches | - |
|
||||||
|
| Backstage Pass | <b>Quality increases by 1;</b><br> <b>Quality increases by 2</b> when there are 10 days or less;<br> <b>Quality increases by 3 </b> when there are 5 days or less;<br> <b>Quality drops to 0</b> after the concert. | - |
|
||||||
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.
|
| Sulfura | **Always 80**. Never changes| Legendary item. Constant quality value. |
|
||||||
|
|
||||||
If your programming language doesn't have an easy way to add a command-line interface, then the TextTest fixture is probably not necessary.
|
|
||||||
|
|
||||||
## Better Code Hub
|
|
||||||
|
|
||||||
I analysed this repo according to the clean code standards on [Better Code Hub](https://bettercodehub.com) just to get an independent opinion of how bad the code is. Perhaps unsurprisingly, the compliance score is low!
|
|
||||||
|
|
||||||
[](https://bettercodehub.com/)
|
|
||||||
|
|||||||
0
Java/gradlew → gradlew
vendored
Executable file → Normal file
0
Java/gradlew → gradlew
vendored
Executable file → Normal file
0
Java/gradlew.bat → gradlew.bat
vendored
0
Java/gradlew.bat → gradlew.bat
vendored
21
license.txt
21
license.txt
@ -1,21 +0,0 @@
|
|||||||
The MIT License (MIT)
|
|
||||||
|
|
||||||
Copyright (c) 2015 @emilybache
|
|
||||||
|
|
||||||
Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
||||||
of this software and associated documentation files (the "Software"), to deal
|
|
||||||
in the Software without restriction, including without limitation the rights
|
|
||||||
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
||||||
copies of the Software, and to permit persons to whom the Software is
|
|
||||||
furnished to do so, subject to the following conditions:
|
|
||||||
|
|
||||||
The above copyright notice and this permission notice shall be included in
|
|
||||||
all copies or substantial portions of the Software.
|
|
||||||
|
|
||||||
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
||||||
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
||||||
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
||||||
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
||||||
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
||||||
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
|
|
||||||
THE SOFTWARE.
|
|
||||||
Loading…
Reference in New Issue
Block a user