Slowly but surely we’re adding to the body of unit tests. From time to time, you need to reflect upon how well these tests document class capabilities. The way I do this is to look at the list of test method names. In Eclipse, I pull up the Members view, which allows me to view only public methods, potentially in sorted order.
In DeckTest, we have the following test methods:
I like the way that this summary tells me the kinds of things I can do and the kinds of things that can happen when I write code to interact with a Deck object. If I need to know more, I can click over to one of these test methods and see the sequence of operations that achieve the specified effect.
The other thing that this test class review can do is suggest areas for improvement. Right now, I note that I might want to combine testCreate and testDeckShuffledOnCreation. The latter test method is not a separate thing I can do with a deck, but instead describes the state of the deck after creating it. Its code probably belongs as part of testCreate.
Next segment: "Refactoring Tests." Meanwhile, here’s the code (source.zip) we’ve built in this installment.