| 5665b19f6012807c7765aa860baa6b01bbcd1c67 |
|
03-Feb-2017 |
Tobias Thierer <tobiast@google.com> |
Improve TreeMapTest
The test was constructing lists of expected keys/values/entries
on top of TreeMap's collection view iterators. These tests might
have missed bugs where the Iterator order was consistent but
wrong. This CL changes the test to explicitly specify the
expected order of elements.
In addition, the order of put() commands populating TreeMap
instances for testing matched the expected iteration order;
this would have missed bugs where TreeMap's iteration order
was based on insertion rather than Comparator order.
This CL changes the order of the put() calls to cover this
behavior aspect.
SpliteratorTester's method signatures were also relaxed to
not rely on particular List implementations for expected
values.
Test: TreeMapTest
Change-Id: Ia649c81cc73d6e66165397f97188ab21ac0f3933
|
| 82637e04484beb79b20b5e619b8ada7403d08c77 |
|
06-Jan-2017 |
Tobias Thierer <tobiast@google.com> |
Check ORDERED Collection Spliterators consistency with Iterator
The documentation at
developer.android.com/reference/java/util/Spliterator.html#ORDERED
requires ordered Collection.spliterator() implementations to have
consistent ordering with Collection.iterator().
This CL adds coverage for this to SpliteratorTester.runOrderedTest().
The fact that this was not previously covered was a contributing
factor in a bug in LinkedHashMap.spliterator()'s order in Android N
not having been found. This bug has already been fixed in Android O.
Note that the same behavior is also covered by tests in
guava-testlib-21.0 that have not yet been added to AOSP.
SpliteratorTester.runOrderedTest() contains some checks for trySplit()
that appear somewhat misplaced since they are unrelated to the ORDERED
characteristic. This CL refactors these to be more meaningful, but
doesn't bother breaking them out into a separate/differently named
test helper method for now.
Some (buggy) collections currently incorrectly report their ordered
spliterators as not having the ORDERED characteristic, so this CL
refrains from adding such an assertion in the shared test logic for
now.
Test: CtsLibcoreTestCases
Bug: 34242647
Bug: 34757089
Change-Id: I8a0b739de8014726c69bc8bb3fccd51c6d26b268
|
| 508f0abe4f8686d29466b2c364cb4f60bf0484b5 |
|
16-Jan-2017 |
Tobias Thierer <tobiast@google.com> |
Basic tests for wrapper Collection factories in java.util.Collections
Basic test coverage for the wrapper Collections constructed by
the following static factory methods in java.util.Collections:
checkedNavigableMap()
checkedNavigableSet()
checkedQueue()
emptyNavigableMap()
emptyNavigableSet()
emptySortedMap()
emptySortedSet()
synchronizedNavigableMap()
synchronizedNavigableSet()
unmodifiableNavigableMap()
unmodifiableNavigableSet()
These 11 methods under test are the only ones currently annotated
@hide in Collections.java; this CL provides sufficient test coverage
for those to be un-hidden in a follow-up CL.
Most (perhaps all) aspects covered by these tests are also covered
by guava-testlib-21.0 tests, but those are not yet available in
AOSP and would take 80min to run, whereas these new tests only take
a few seconds to run.
SpliteratorTester previously contained some overly strict assertions
that Spliterator.trySplit() != null. This CL relaxes this assumption
for non-empty spliterables but adds a separate assertSupportsTrySplit()
check in the places that previously exercised this strict test logic;
Where the old tests appeared to be testing the wrong collection (e.g.
in HashSetTest), this CL asserts the support for trySplit on what
appears to be the correct Collection, but does not otherwise fix the
existing test code.
Bug: 29935305
Test: CtsLibcoreTestCases
Change-Id: Ibeac242bb60df7b06a1c8c80dc744707f734d91c
|
| 9efb6d12ce4d2ffedb73d6e9887ea2c89f8ec129 |
|
08-Jun-2016 |
Narayan Kamath <narayan@google.com> |
Update HashMap, HashSet, LinkedHashMap to JDK8u60.
Added tests for:
- entrySet()/keySet()/values() spliterators (LinkedHashMap
has completely new implementations)
- LinkedHashMap.eldest (Android specific API, previously
existed but was untested)
- naming of nested class LinkedHashMap.LinkedHashMapEntry
- tweaked test for Map.getOrDefault() method so it's useful
for LinkedHashMap
This CL doesn't touch HashSetTest since it already covered
spliterator() and serialization.
Test: Ran all libcore tests.
Bug: 29935305
Change-Id: I9d991a08c403b83b15e9c88ce97cbd5cd77a8bcf
|
| 8b056f0b15bc1e45da8d4c504353b05e681ac013 |
|
04-Mar-2016 |
Narayan Kamath <narayan@google.com> |
Add java.lang.Iterable.spliterator() and supporting classes.
The only android specific changes here are to HashMap - their
spliterators add Spliterator.ORDERED if the HashMap is an instance
of a LinkedHashMap.
There's some degree of duplication between the test code used to
exercise primitive arrays (Arrays / Spliterators provide similar
APIs). These differences are quite hard to consolidate, since the
Arrays version declares that their Spliterators are ORDERED but
the Spliterator version doesn't. The latter also allows us to declare
additional Spliterator characteristics.
bug: 27426688
Change-Id: I191a9319d4af7e22834f2d91f73634a227b36bc2
|
| 4c89023ef86f29fa9add7db2574f2169fe842577 |
|
04-Mar-2016 |
Narayan Kamath <narayan@google.com> |
Add java.lang.Iterable.spliterator() and supporting classes.
The only android specific changes here are to HashMap - their
spliterators add Spliterator.ORDERED if the HashMap is an instance
of a LinkedHashMap.
There's some degree of duplication between the test code used to
exercise primitive arrays (Arrays / Spliterators provide similar
APIs). These differences are quite hard to consolidate, since the
Arrays version declares that their Spliterators are ORDERED but
the Spliterator version doesn't. The latter also allows us to declare
additional Spliterator characteristics.
(cherry-picked from commit ed21aa3a8dcd34eca6f0317eeb683e7afdc825b9)
bug: 27426688
Change-Id: I191a9319d4af7e22834f2d91f73634a227b36bc2
|