On Fri, 24 May 2002, Jack, Paul wrote:
> I completed all the TODO and XXX items in TestMap. Some of
> the Map implementations (notably MultiHashMap) intentionally
> violate the Map contract, so I overrode some of the new
> methods in concrete TestMap subclasses.
This 3-day weekend is now coming to a close, and I haven't gotten nearly
as much accomplished as I would have hoped. I have, however, gotten a
chance to review the patch to the testing code. In a second or two, I'll
be committing your patch with the following modifications:
- Wrapped some long lines to fit within 80 columns.
- Added javadoc documentation to the new methods.
- In testEntrySetContainsAll(), moved the containsAll check inside the
loop to check after each expected item is added to the collection
argument.
- In testEntrySetRemove2(), changed the "notAKey" and "notAValue" to a
real key and real value as returned from getKeys and getValues, but
executed the test on an empty map. Otherwise, a type specific map that
may be added in the future may throw a class cast or other exception
because the key and/or value are not of the appropriate type. Similar
changes were made elsewhere for the same reasoning as described below.
- In testMapGet, I made sure the value is still being returned correctly
when the value in a mapping is null rather than just ignoring mappings to
null values.
- Uncommented the toString() method you added, but changed it to be
"valid" for all maps (i.e. do as much checking as possible considering
the format of the string returned from toString is not defined.)
- In testMapPut, changed your hardcoded key ("1") and value ("One") to be
those returned from getSampleKeys and getSampleValues. For the second
put, I used the values from getNewSampleValues.
- In testMapPutAll, changed hardcoded values to those from getSampleKeys
and getSampleValues.
- In testMapRemove, changed hardcoded values to those from getSampleKeys.
- I didn't take much for testMapValues because the values within a
collection are not necessarily sortable. Instead, I rewrote it to compare
the collections in a different way. This change allowed a test of the
BeanMap.values() method rather than overriding it to not test anything.
- In TestDoubleOrderedMap, clarified the documentation of the overridden
test.
- In TestMultiHashMap, added TODO for reimplementing the tests to ensure
the values are appropriate collections rather than just ignoring the tests
altogether.
> There is still some work to be done in that keySet()
> and values() collection views are inadequately tested.
definately.
The testing approach in TestMap doesn't extend well. That is, if another
collection returns a map, there's no easy way to use the same testing code
to test the returned map. In other words, if we use the same approach in
TestMap for TestList and TestSet, etc., then that testing code can't be
reused to test the collection views of Map. Long term, I'd want to see a
much more flexible mechanism for testing collections that can be reused to
test small-collection views of larger collections.
If only there where 48 hours in a day.
Thanks, Paul, for taking the time to fill in these extra test methods!
regards,
michael
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
