> On 14 Dec 2016, at 19:54, Martin Buchholz <[email protected]> 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.
