RFR: jsr166 jdk9 integration wave 12

[Martin Buchholz]

Regarding the testing mess:

I think there should be a project to use Junit 5 features to create
interface based tests.  Then a BlockingDeque implementation could easily
pull in all the tests already written for BlockingDeque and its
superinterfaces.  Tests for interfaces would be found in a predictable
location, e.g. test/j/u/c/BlockingDeque/.  jtreg probably needs to have
junit 5 support added.  There should be testing folk excited about doing
this!  (The historic preference to have such tests in the JCK is an
impediment ... )

On Wed, Oct 19, 2016 at 12:19 PM, Stuart Marks <stuart.marks at oracle.com>
wrote:

>
>
> On 10/18/16 11:00 AM, Martin Buchholz wrote:
>
>> There's already a certain amount of mixing, e.g. stream tests sometimes
>> test
>> j.u.c. and Queue tests sometimes test all the Queue implementations.
>> Unlike
>> non-test code, some redundancy and divergence of testing frameworks and
>> styles
>> is fine.  I still haven't found a way of writing shared tests for
>> implementations of an interface that I really like.
>>
>
> It's probably the case that divergence of testing frameworks is
> unavoidable, or at least it's impractical. I doubt that it's worthwhile to
> rewrite all the straight jtreg tests into TestNG, or JUnit, or whatever.
> But I'd draw the line before saying this is "fine." [1]
>
> Maintaining the tests' organization is pretty important. Most of the
> collections tests are in jdk/test/java/util though they're spread around a
> bit uncomfortably even here. But now it's, oh, ArrayDeque and
> ArrayList.removeIf tests are over *here* instead. Having things spread
> around increases the likelihood of cases being missed or being tested
> redundantly.
>
> The test groups have to be maintained as well. I know I've been bitten by
> problems (not in collections) where I *thought* I had run the right set of
> tests, but it ended up that I hadn't, resulting in me breaking the build.
> As it turns out, jdk_collections_core doesn't include any ArrayDeque tests.
> Hmmm. Well, maybe jdk_collections_core isn't useful. It would have been
> nice to know this when I added it last year. :-/ [2]
>
> As things stand, I'm basically OK with this changeset going in. But it
> does seem to highlight some areas that need some future cleanup,
> particularly in the tests and the test group declarations.
>
> s'marks
>
> [1] http://knowyourmeme.com/memes/this-is-fine
>
> [2] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/7a0c06013ae6
>
>