Abstract test class for {@link java.util.Collection} methods and contracts.
You should create a concrete subclass of this class to test any custom {@link Collection} implementation. At minimum, you'll have toimplement the {@link #makeCollection()} method. You might want tooverride 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):
- {@link #getFullElements()}
- {@link #getOtherElements()}
Supported Operation Methods Override these if your collection doesn't support certain operations:
- {@link #isAddSupported()}
- {@link #isRemoveSupported()}
- {@link #areEqualElementsDistinguishable()}
- {@link #isNullSupported()}
- {@link #isFailFastSupported()}
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 collections15 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 collections15,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:
- {@link #makeConfirmedCollection()}
- {@link #makeConfirmedFullCollection()}
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 collections15.
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.
@author Rodney Waldhoff
@author Paul Jack
@author Michael A. Smith
@author Neil O'Toole
@author Matt Hall, John Watkinson, Stephen Colebourne
@version $Revision: 1.1 $ $Date: 2005/10/11 19:11:58 $