Examples of org.apache.commons.collections.map.AbstractTestMap

• org.apache.commons.collections.map.AbstractTestMap
  Abstract test class for {@link java.util.Map} methods and contracts.

  The forces at work here are similar to those in {@link AbstractTestCollection}. If your class implements the full Map interface, including optional operations, simply extend this class, and implement the {@link #makeEmptyMap()} method.

  On the other hand, if your map implementation is weird, you may have to override one or more of the other protected methods. They're described below.

  Entry Population Methods

  Override these methods if your map requires special entries:

  • {@link #getSampleKeys()}
  • {@link #getSampleValues()}
  • {@link #getNewSampleValues()}
  • {@link #getOtherKeys()}
  • {@link #getOtherValues()}

  Supported Operation Methods

  Override these methods if your map doesn't support certain operations:

  • {@link #isPutAddSupported()}
  • {@link #isPutChangeSupported()}
  • {@link #isSetValueSupported()}
  • {@link #isRemoveSupported()}
  • {@link #isGetStructuralModify()}
  • {@link #isAllowDuplicateValues()}
  • {@link #isAllowNullKey()}
  • {@link #isAllowNullValue()}

  Fixture Methods

  For tests on modification operations (puts and removes), fixtures are used to verify that that operation results in correct state for the map and its collection views. Basically, the modification is performed against your map implementation, and an identical modification is performed against a confirmed map implementation. A confirmed map implementation is something like java.util.HashMap, which is known to conform exactly to the {@link Map} contract. After the modification takes placeon both your map implementation and the confirmed map implementation, the two maps are compared to see if their state is identical. The comparison also compares the collection views to make sure they're still the same.

  The upshot of all that is that any test that modifies the map in any way will verify that all of the map's state is still correct, including the state of its collection views. So for instance if a key is removed by the map's key set's iterator, then the entry set is checked to make sure the key/value pair no longer appears.

  The {@link #map} field holds an instance of your collection implementation.The {@link #entrySet}, {@link #keySet} and {@link #values} fields holdthat map's collection views. And the {@link #confirmed} field holdsan instance of the confirmed collection implementation. The {@link #resetEmpty()} and {@link #resetFull()} methods set these fields to empty or full maps, so that tests can proceed from a known state.

  After a modification operation to both {@link #map} and {@link #confirmed}, the {@link #verify()} method is invoked to compare the results. The{@link #verify} method calls separate methods to verify the map and its threecollection views ( {@link #verifyMap}, {@link #verifyEntrySet}, {@link #verifyKeySet}, and {@link #verifyValues}). You may want to override one of the verification methodsto perform additional verifications. For instance, TestDoubleOrderedMap would want override its {@link #verifyValues()} method to verify that the values are unique and inascending order.

  Other Notes

  If your {@link Map} fails one of these tests by design, you may still usethis base set of cases. Simply override the test case (method) your map fails and/or the methods that define the assumptions used by the test cases. For example, if your map does not allow duplicate values, override {@link #isAllowDuplicateValues()} and have it return false @author Michael Smith @author Rodney Waldhoff @author Paul Jack @author Stephen Colebourne @version $Revision: 1.16 $ $Date: 2004/06/07 23:14:40 $

Related Classes of org.apache.commons.collections.map.AbstractTestMap