| .. | ||
| gradle/wrapper | ||
| src | ||
| .gitignore | ||
| build.gradle.kts | ||
| gradlew | ||
| gradlew.bat | ||
| img_1.png | ||
| img.png | ||
| README.md | ||
| texttest_rig.py | ||
Gilded Rose starting position in Kotlin
Run the Text Fixture from Command-Line
./gradlew -q text
Specify Number of Days
For e.g. 10 days:
./gradlew run --args 10
You should make sure the gradle commands shown above work when you execute them in a terminal before trying to use TextTest (see below).
Run the TextTest approval test that comes with this project
There are instructions in the TextTest Readme for setting up TextTest. What's unusual for the Java version is there are two executables listed in config.gr for Java. One uses Gradle wrapped in a python script, the other relies on your CLASSPATH being set correctly in environment.gr.
Starting Point
Project info
- Code is highly unreadable and impossible to extend
- Algorithm and test cases are unknown, I do not trust that
TexttestFixturescovers all paths so I want to validate it with jacoco - Codebase is just 60 LOC and edge-values seems to be small values
Plan of action
- Generate all test cases / convert
TexttestFixturesto tests - Break complex statements, make code longer and simpler
- understand algorithm and propose better solution
Execution
Testing TexttestFixtures
TexttestFixtures indeed do not cover all paths, based on jacoco coverage:

There are two ways to advance:
- manually craft extra test cases
- auto generate a bunch of test cases
I prefer to go with (2) because it seems to me to be more resilient way. I need to check if execution time is not bloated. Also minimize number of test cases.
Test cases generation
I copied GildedRose class to PlatinumRose and implemented a test which executes both app and then compare results. Time of execution is under 500ms which is great. Also, all paths are covered:
One noticeable fact i that items are declared as var which makes it possible to update during/after execution.
In my opinion this is a design issue, code-smell and I'm going to change it to val.
So far I only changed Item to data class so that object comparison is easier, also it seems to be DTO/record so it suppose to be a data class
updateQuality cleanup
I cleaned up updateQuality method, split it into 3 separate methods for each case - verified all tests still pass. During refactor I also found README file in a main directory in which algorithm was explained - there are extra constraints that are not covered in code:
- quality of Sulfuras is max 80
- quality cannot be negative
At this point code is readable but not so extensible because all algos are in a single class which might grow to infinity. The usual way to handle this situation is to go with OO approach - I cannot modify Item class so I will implement new one and its specifications.
