You should create a concrete subclass of this class to test any custom {@link Collection} implementation. At minimum, you'll have to implement the {@link #makeCollection()} method. You might want to override some of the additional public methods as well:
Element Population Methods
Override these if your collection restricts what kind of elements are allowed (for instance, if null is not permitted):
Supported Operation Methods
Override these if your collection doesn't support certain operations:
Fixture Methods
Fixtures are used to verify that the the operation results in correct state for the collection. Basically, the operation is performed against your collection implementation, and an identical operation is performed against a confirmed collection implementation. A confirmed collection implementation is something like java.util.ArrayList, which is known to conform exactly to its collection interface's contract. After the operation takes place on both your collection implementation and the confirmed collection implementation, the two collections are compared to see if their state is identical. The comparison is usually much more involved than a simple equals test. This verification is used to ensure proper modifications are made along with ensuring that the collection does not change when read-only modifications are made.
The {@link #collection} field holds an instance of your collectionimplementation; the {@link #confirmed} field holds an instance of theconfirmed collection implementation. The {@link #resetEmpty()} and {@link #resetFull()} methods set these fields to empty or full collections,so that tests can proceed from a known state.
After a modification operation to both {@link #collection} and{@link #confirmed}, the {@link #verify()} method is invoked to comparethe results. You may want to override {@link #verify()} to performadditional verifications. For instance, when testing the collection views of a map, {@link AbstractTestMap} would override {@link #verify()} to makesure the map is changed after the collection view is changed.
If you're extending this class directly, you will have to provide implementations for the following:
Those methods should provide a confirmed collection implementation that's compatible with your collection implementation.
If you're extending {@link AbstractTestList}, {@link AbstractTestSet}, or {@link AbstractTestBag}, you probably don't have to worry about the above methods, because those three classes already override the methods to provide standard JDK confirmed collections.
Other notes
If your {@link Collection} fails one of these tests by design,you may still use this base set of cases. Simply override the test case (method) your {@link Collection} fails. @version $Revision: 1.8 $ $Date: 2004/06/01 22:55:14 $ @author Rodney Waldhoff @author Paul Jack @author Michael A. Smith @author Neil O'Toole @author Stephen Colebourne
| |
| |
| |
| |
| |