Our test is far from being readable. A test case is readable if you look at it and in 15 seconds you can tell what it does. It assumes, of course, some experience in Java on behalf of the reader, but you get the point. Our test is cluttered with support classes that are not core to the test.

Our test also hardly validates that the code is working properly. It actually does not. There are some bugs in it that I put there deliberately, which we will locate and zap in the following sections. One single test that sorts a single String array is far from validating a sort implementation. If I were to extend this test to a real-world test, we would need methods that would have the name canSortEmptyCollection, canSortOneElementCollection, canSortTwoElements, canSortReverseOrder, or canSortAlreadySorted. If you look at the names, you will see what tests we need. Coming from the nature of the sort problem, an implementation may be reasonably sensitive to errors in these special cases.

What are the good points in our unit test, in addition to it being an acceptable demonstration tool?