RFR: jsr166 jdk9 integration wave 13

[Paul Sandoz]

> On 14 Dec 2016, at 19:54, Martin Buchholz <martinrb at google.com> wrote:
> 
> I see that SpliteratorTraversingAndSplittingTest tests far more collection implementations than Collection8Test does, but we now have tests that caught spliterator bugs not caught by SpliteratorTraversingAndSplittingTest.  Our tests of Spliterators are often comingled with other test methods, e.g. in testIteratorEquivalence.
> 

Yes, the scopes are different and intersect somewhat.

The Spliterator traversing tests do not test for weakly consistent behaviour of concurrent collections.

I recently separated out the fail fast and late binding tests (so ArrayDeque is included in the latter but not the former). Those do not test concurrent collections, since i think a more specific set of weakly consistent tests are needed.

It would be useful to refactor out the underlying spliterator tests into a library, since they can be used for collections or for the spliterator obtained from the head stream. (There is a bug open to track that.)

Paul.



> So, possible future work: testing could be improved in both dimensions of increasing number of implementations and increasing number of tests.