RFR: 8024014 & 8024015 : (xs) TEST.groups updates

[Martin Buchholz]

I used to run collection/concurrency tests regularly.
It's hard to separate collections and concurrency, unless perhaps you make
concurrent a subset of collections.  You can come pretty close to testing
just collections by running all tests in util with names matching
Map|List|Collection|Queue|Deque|Set (and I've probably forgotten some).  I
agree it's hard to maintain.


On Thu, Aug 29, 2013 at 10:37 PM, Alan Bateman <Alan.Bateman at oracle.com>wrote:

> On 30/08/2013 01:13, Mike Duigou wrote:
>
>> Hello all;
>>
>> This is a review for two changesets. The first change (JDK-8024014)
>> splits up the jdk_util test group a bit by introducing three sub-groups,
>> jdk_collections, jdk_stream and jdk_concurrent. The main advantage is that
>> it's easier/quicker to test individual components. The intent is that the
>> test groups are aligned with bug database sub-components.
>>
>> The second change moves some important lambda related tests from
>> languishing in obscurity in the jdk_other group to the jdk_lang group to
>> reflect their importance and relation to other tests. These tests are
>> contained in the jdk/lambda directory.
>>
>> The combined webrev is here:
>>
>> http://cr.openjdk.java.net/~**mduigou/JDK-8024015/0/webrev/<http://cr.openjdk.java.net/~mduigou/JDK-8024015/0/webrev/>
>>
>> The effect of these changes won't be visible to most people until
>> JDK-8015068 is integrated.
>>
>> Thanks,
>>
>> Mike
>>
> The jdk_other group was initially created to match the existing jdk_other
> make file target so this is why jdk/lambda is there. I agree with moving it
> as it is somewhat obscure.
>
> I'm not sure about splitting up jdk_util as proposed as it doesn't look
> very maintainable. Have you considered just limiting this to simple groups
> for java/util/stream/** and java/util/concurrent/** and not try carve up
> the tests in java/util? If someone is changing something in the collection
> classes then is it a big deal to run all of the java/util/** tests? If
> there are good reasons then maybe it's time to look at how the tests are
> organized instead.
>
> -Alan.
>