What I’ve learned by doing the Gilded Rose Kata (4 refactoring tips)
blog.lunarlogic.io
blog.lunarlogic.io
What I remember most about it, other than the complicated logic, was using 'coverage' in branch mode to find two places where the manually developed and pretty comprehensive unit test suite was incomplete.
How does one pick the test cases for something like the GildedRose? Emily Bache, who provided the test cases for this essay and who ran the Python user group kata that I participated in, developed the test cases manually.
Are those provide test cases sufficient? As this essay shows, they are not.
The solution shown here "recorded bunch of input examples and output results from the program we wanted to refactor." However, are those seeded versions themselves sufficient?
Another solution is to use branch coverage testing to identify untested paths, and write unit tests which specifically target those paths. When I did this using Bache's unit test suite, I found that two branches were not exercised.
Even coverage analysis may not be sufficient. I mention it to suggest an alternate technique that I found useful in working with this kata.
Coverage assisted test development is, in my opinion, an underused technique.
"The solution shown here "recorded bunch of input examples and output results from the program we wanted to refactor." However, are those seeded versions themselves sufficient?" Golded Master tests are sufficient because I recorded all possible cases of inputs/outputs for reasonable amount of sell in days. See https://github.com/ArturT/GildedRose-Refactoring-Kata/blob/s... https://github.com/ArturT/GildedRose-Refactoring-Kata/blob/s...
"Even coverage analysis may not be sufficient." Agree.
"Coverage assisted test development is, in my opinion, an underused technique." I guess you're right. I wouldn't relay only on test coverage.