RFR: 8024014 & 8024015 : (xs) TEST.groups updates
Mike Duigou
mike.duigou at oracle.com
Fri Aug 30 20:30:38 UTC 2013
On Aug 29 2013, at 22:37 , Alan Bateman 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/
>>
>> 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?
Did you see David Holmes' suggestion? Do you think it's adequate? I agree about the maintainability aspect as I really felt guilty re-creating FILES_JAVA.gmk...
> If someone is changing something in the collection classes then is it a big deal to run all of the java/util/** tests?
Having a smaller subset (larger than a singleton) is always of some value. Collections by itself is about 30% of total util so there is a nice turn around reduction for iterative dev/test.
> If there are good reasons then maybe it's time to look at how the tests are organized instead.
>
> -Alan.
More information about the core-libs-dev
mailing list