Actually I believe that Bobby Johnson is missing a test that when the sellIn date is past and the initial quality is 1, then quality is 0 (and not -1).
Apart from this, I think that these tests should be refactored. There is a lot of duplication, expecially in the first line of most tests. You would have to pay for this duplication if the constructor for the GildedRose class were to change. And if you do remove this duplication and get to something like
givenItem(so-and-so); updatedQualityIs(so-and-so)
you can explain the business case more clearly, by simulating fit tables in NUnit.
Thanks for advertising this kata! It was fun to write the tests.
3 comments:
Actually I believe that Bobby Johnson is missing a test that when the sellIn date is past and the initial quality is 1, then quality is 0 (and not -1).
Apart from this, I think that these tests should be refactored. There is a lot of duplication, expecially in the first line of most tests. You would have to pay for this duplication if the constructor for the GildedRose class were to change. And if you do remove this duplication and get to something like
givenItem(so-and-so); updatedQualityIs(so-and-so)
you can explain the business case more clearly, by simulating fit tables in NUnit.
Thanks for advertising this kata! It was fun to write the tests.
So you're saying that although Bobby's tests are Readable, they might not be so Updatable if for example the constructor for GildedRose changed.
I'd like to see some tests for this written as a fit table (hint!)
Glad you enjoyed doing the kata.
Here is my solution: https://gist.github.com/xpmatteo/5243745
In retrospect, the table-style test could have been applied to all cases, but this is how I left it at the end of my exercise.
Post a Comment